نوشته های عرفان جعفری زمان

بک آپ پوستگرس با pq_dumpall

عرفان جعفری زمان — Sun, 14 May 2023 12:08:58 +0330

برای بکاپگیری از تمام اطلاعات پوستگرس از دستور pq_dumpall می توان استفاده کرد یا به ازای هر یک از دیتابیس های موجود در پوستگرس دستور pq_dump را اجرا نمود و فقط از دیتابیس مورد نظر به صورت زیر بکاپ گرفت:$ pg_dump -h host -U username -p port dbname > db.sql$ Pg_dumpall -h host -U username -p port -f db.sqlحال اگر از تمام اطاعات پوستگرس با Pg_dumpall بکاپ گرفته شده با اجرا bash script زیر می توان بکاپ یک دیتابیس خاص را استخراج کرد:$ cat pgdump.sh#!/bin/bash[ $# -lt 2 ] && { echo "Usage: $0 "; exit 1; }sed "/connect.*$2/,\$!d" $1 | sed "/PostgreSQL database dump complete/,\$d"$ ./pgdump.sh db.sql databasename >> backup.sqlبعد از اتمام دستور بالا می توان بکاپ موجود را در همان دیتابس قبلی با دستور زیر بازیابی نمود:$ psql -U username -d dbname -f backup.sql -h host -p portو اگر نیاز به بازیابی بکاپ در دیتابیس جدید باشد ابتدا خط اول موجود در backup.sql را پاک کرده و دستور زیر را اجرا نمایید ( C- برای ساخت دیتابیس در صورت عدم وجود می باشد):$ cat backup.sql\connect old-dbname...$ psql -U username -C -d new_db -f backup.sql -h host -p port

جمع آوری لاگ های Kubernetes Pods با استفاده از Fluentd - بخش دوم

عرفان جعفری زمان — Sat, 16 Jul 2022 16:52:04 +0430

در بخش قبل کانفیگ forwarder بررسی گردید و در این بخش تنظیمات aggregator مورد بررسی قرار می گیرد.یک نمونه از کانفیگ aggregator به صورت زیر می باشد: # Ignore fluentd own events @type null @include fluentd-inputs.conf @include fluentd-output.conf {{- if .Values.metrics.enabled }} @include metrics.conf {{- end }} fluentd-inputs.conf: | # TCP input to receive logs from @type forward bind 0.0.0.0 port 24224 # HTTP input for the liveness and readiness probes @type http bind 0.0.0.0 port 9880 fluentd-output.conf: | # Throw the healthcheck to the standard output @type stdout # Send the logs to the standard output @type elasticsearch include_tag_key true host eck-es-http.logs.svc port 9200 user elastic password password logstash_format false index_name fluentd-${tag} logstash_prefix fluentd target_index_affinity true include_timestamp true deflector_alias fluentd-${tag} rollover_index true application_name example template_name fluentd-${tag} template_file /voho/template customize_template {"<>":"fluentd-${tag}"} template_overwrite true metrics.conf: | # Prometheus Exporter Plugin # input plugin that exports metrics @type prometheus port {{ .Values.metrics.service.port }} # input plugin that collects metrics from MonitorAgent @type prometheus_monitor host ${hostname} # input plugin that collects metrics for output plugin @type prometheus_output_monitor host ${hostname} # HTTP input for the liveness and readiness probes @type http bind 0.0.0.0 port 9880 این بخش از تنظیمات منابع ورودی لاگ های را مشخص می کند که اولی از لاگ های forwarder ها که به پورت ۲۴۲۲۴ سرویس fluentd aggregator ارسال می کردند و دومی هم لاگ ها readiness و liveness استفاده می کنند. @type elasticsearch include_tag_key true host eck-es-http.logs.svc port 9200 user username password password logstash_format false index_name fluentd-${tag} logstash_prefix fluentd target_index_affinity true include_timestamp true deflector_alias fluentd-${tag} rollover_index true application_name example template_name fluentd-${tag} template_file /voho/template customize_template {"<>":"fluentd-${tag}"} template_overwrite true افزونه elasticsearch برای برای ارتباط برقرار کردن بین fluentd و elasticsearch می باشد که در مشخص می کند لاگ به چه index و با چه زمانی و ... به سمت elastic ارسال گردد.include_tag_keyمعیین می کند که tag به عنوان یک فیلد در لاگ های ارسالی وجود داشته باشد یا خیر.hostآدرس elasticsearch را مشخص می کند. (اگر الستیک داخل کلاستر می باشد می توان آدرس سرویس را داد و گر نه باید ادرس url الستیک داده شود.)نحوه تعیین آدرس سرویس به صورت servicename>-.svc> می باشد.port شماره port الستیک را مشخص می کند.user مقدار username الستیک را می گیرد.passwordمقدار password الستسک را می گیرد.logstash_formatمعین می کند که اسم index در الستیک فرمت logstash (indexname-date) را داشته باشند یا خیر.index_nameاسم index ساخته شده در الستیک را معین می کند.logstash_prefix fluentdمقداری که به اول indexname اضافه می شود (در rollover کردن) را مشخص می کند.4معین می کند که در زمانی که index ها با تگ تاریخ ساخته می شوند اگر index روز های قبل به مقدار حجم حداکثر نرسیده باشد داده ها در همان index ذخیره شوندمزیت این کار این می باشد که تعداد index ها کم می شود م سرعت جستوجو افزایش می یابد.include_timestampمعین می کند که فیلد timestamp در لاگ ها وجود داشته باشند یا خیر.rollover_index با فعال کردن این بخش داده ها با فرمت اسم index به صورت ذخیره می شوند.deflector_aliasاگر یک index نیازمند rollover باشد باید یک alias برای آن تعریف گردد که این گزینه آن را برای index ها مشخص می کند.application_nameاین قسمت در rollover استفاده می شود.template_nameبرای این که برای هر لاگ با tag مشخص template به صورت خودکار ساخته شود می توان یک فایل template مشخص کرد که برای index آن لاگ ها template را اضافه کند.template_fileمحل فایل template را در pod fluentd مشخص می کند.یک نمونه از فایل template در اخر کانفیگ آورده شده است.customize_templateبرای این که در فایل template تعریف شده مقداری به صورت ثابت یا متغیر تعریف شوند از این بخش استفاده می شود.به عنوان مثال در فایل template مقدار tag به صورت متغییر تعریف شده است که در این بخش مقدار tag از لاگ ها گرفته می شود.template_overwriteمعین می کند اگر در فایل template اگر تغییری داشتیم در template های ساخته شده اعمال شود یا خیر.نمونه از یک فایل template:{ "order": 100, "index_patterns": [ "<>-*" ], "settings": { "index": { "lifecycle": { "name": "ILM", "rollover_alias": "<>" }, "refresh_interval": "15s", "number_of_shards": "1", "number_of_replicas": "1" } }, "aliases": { "all-<>": {} } }این فایل باید در image aggregator قرار گیرد که می توان یک dockerfile ایجاد کرده و آن را build کرد:FROM docker.io/bitnami/fluentd:1.14.4-debian-10-r11 USER root RUN mkdir /example COPY template /example/template

جمع آوری لاگ های Kubernetes Pods با استفاده از Fluentd - بخش اول

عرفان جعفری زمان — Sat, 16 Jul 2022 15:34:20 +0430

نرم افزار Fluentd یک ابزار مبتنی بر فضای ابری open-source و کاملا رایگان برای جمع آوری لاگ است که کاربر را قادر می ‌سازد معماری سازگار Log All Everything را با سیستم های خیلی زیادی را داشته باشد. این ابزار به زبان C نوشته شده است و روی تمام سیستم عامل ها از جمله ویندوز و لینوکس اجرا می شود و تحت لیسانس Apache 2.0 است. همچنین می توان از قالب JSON برای ساختار دادن به داده استفاده می کند. از جمله مزایای آن می توان به کم حجم بودن آن و انعطاف پذیر بودن آن در تعداد کاربران استفاده کننده از آن اشاره کرد.در کلاستر کوبرنتیز لاگ های stdout و stderr پادها در نودهای کلاستر در مسیر .../var/log/containers/ جمع آوری می شوند و می توان با کانفیگ کردن fluentd برای جمع آوری و ارسال آن ها, لاگ های پادها را در الستیک داشت. معماری fluentd به گونه می باشد که در هر node یک fluentd به صورت daemon set با اسم forwarder لاگ ها را از پوشه لاگ جمع آوری می کند و به سمت یک fluentd به اسم aggregator می فرستد که این aggregator لاگ ها را به سمت elasticsearch می فرستد.برای نصب و کانفیگ fluentd از helm chart آن استفاده می کنیم که می توان از آدرس github.com/bitnami/charts/tree/master/bitnami/fluentd دانلود کرد.برای ارسال لاگ باید قسمت configMapFiles در forwarder و aggregator کانفیگ شوند که در زیر اورده شده است: configMapFiles: fluentd.conf: | # Ignore fluentd own events @type null @include fluentd-inputs.conf @include fluentd-output.conf {{- if .Values.metrics.enabled }} @include metrics.conf {{- end }} fluentd-inputs.conf: | # HTTP input for the liveness and readiness probes @type http port 9880 # Get the logs from the containers running in the node @type tail path /var/log/containers/*.log pos_file /opt/bitnami/fluentd/logs/buffers/fluentd-docker.pos exclude_path /var/log/containers/*fluentd*.log tag kubernetes.* time_key @timestamp time_format %Y-%m-%dT%T.%L%Z read_from_head true @type json @type parser key_name "$.log" hash_value_field "log" reserve_data true @type json emit_invalid_record_to_error # enrich with kubernetes metadata @type kubernetes_metadata @type rewrite_tag_filter key $.kubernetes.labels.app_kubernetes_io/name pattern ^(.+)$ tag $1 fluentd-output.conf: | # Throw the healthcheck to the standard output instead of forwarding it @type stdout # Forward all logs to the aggregators @type forward host fluentd-0.fluentd-headless.logs.svc.cluster.local port 24224 @type file timekey 30s flush_mode interval total_limit_size 20GB path /opt/bitnami/fluentd/logs/buffers/logs.buffer_${tag}_${chunk_id} retry_forever true retry_type exponential_backoff retry_exponential_backoff_base 2 retry_max_interval 1h flush_thread_count 2 flush_interval 5s metrics.conf: | # Prometheus Exporter Plugin # input plugin that exports metrics @type prometheus port {{ .Values.metrics.service.port }} # input plugin that collects metrics from MonitorAgent @type prometheus_monitor host ${hostname} # input plugin that collects metrics for output plugin @type prometheus_output_monitor host ${hostname} # input plugin that collects metrics for in_tail plugin @type prometheus_tail_monitor host ${hostname} @type prometheus name fluentd_input_status_num_records_total type counter desc The total number of incoming records tag ${tag} hostname ${hostname} حال در زیر به تعیین جز به جز کانفیگ فوق می پردازیم: @type tail path /var/log/containers/*.log pos_file /opt/bitnami/fluentd/logs/buffers/fluentd-docker.pos exclude_path /var/log/containers/*fluentd*.log tag kubernetes.* time_key @timestamp time_format %Y-%m-%dT%T.%L%Z read_from_head true @type json @type tailمشخص می کند نوع منبع لاگ به چه صورتی باشد که tail یعنی به از یک فایل لاگ ها را بخواند.pathمسیر فایل لاگ را به fluentd می دهد.pos_fileمسیری را مشخص می کند که در آن تعیین می شود لاگ فایل تا چه سطری فرستاده شده است و از کجا باید ارسال لاگ ادامه پیدا کند.exclude_pathمسیر فایل هایی که نباید ارسال شوند را معین می کند.tagبه لاگ های ارسالی یک tag اضافه می کند که از آن برای تفکیک لاگ ها در ارسال به جاهای مختلف استفاده می شود (به صورت پیش فرض اسم فایل به عنوان tag انتخاب می شود و در این کانفیگ .kubernetes به اول tag اضافه می شود)time_keyاسم فیلد زمان را در لاگ ها را مشخص می کند.time_formatفرمت مقدار فیلد زمان را مشخص می کند.read_from_headدر زمان tail کردن فقط لاگ های جدیدی که اضافه شده اند ارسال می شوند ولی در با true کردن این مقدار شروع به tail کردن از اول فایل می کند.@type jsonاین قسمت که در pars قرار داد نوع لاگ های موجود در فایل لاگ را تعیین می کند. @type parser key_name "$.log" hash_value_field "log" reserve_data true @type json emit_invalid_record_to_error تنظیمات فوق برای تعیین نوع لاگ یک فیلد خاص می باشد. در parser پیشین ما فرمت کلی لاگ ارسال شده را مشخص کردیم ولی در اینجا فرمت یک فیلد خاص را مشخص می کنیم فیلد log فیلدی می باشد که اطلاع نوشته شده در فایل لاگ را در بردارد که در بالا مشخص شده است که این فیلد به صورت json هستند و لاگ های غیر josn دور ریخته می شوند.(پارامتر emit_invalid_record_to_error این لاگ ها به صورت error در ارسال می کند) @type rewrite_tag_filter key $.kubernetes.labels.app_kubernetes_io/name pattern ^(.+)$ tag $1 حال در این قسمت با استفاده از افزونه rewrite_tag_filter تگ لاگ ها را عوض کرده و بر اساس اسم برنامه قرار می دهیم ( می توان به جای kubernetes.labels.app_kubernetes_io/name.$ که یک فیلد از لاگ های ارسالی هست از متغییر های دیگری نیز استفاده کرد) @type forward host fluentd-0.fluentd-headless.logs.svc.cluster.local port 24224 @type file timekey 30s flush_mode interval total_limit_size 20GB path /opt/bitnami/fluentd/logs/buffers/logs.buffer_${tag}_${chunk_id} retry_forever true retry_type exponential_backoff retry_exponential_backoff_base 2 retry_max_interval 1h flush_thread_count 2 flush_interval 5s در تنظیمات این قسمت لاگ ها از forwarder به سمت aggregator ارسال می کنیم.hostآدرس سرویس aggregator می باشد.portشماره port سرویس aggregator می باشد. قسمت buffer برای جلوگیری از حذف شدن لاگ ها و هم افزایش performance با کاهش دفعات اتصال به aggregator می باشد. برای بافر کردن fluentd شروع به جمع کردن لاگ ها درون chunk file می کند که در این تنظیمات مشخص شده فایل ها بر اساس زمان و tag لاگ ها ایجاد شوند.typeنوع chunk ها مشخص می کند.timekeyاین قسمت تعیین می کند که فایل های جدید chunk با چه interval ایجاد شوندflush_modeفلاش یعنی زمانی که این chunk ها به سمت aggregator فرستاده می شوند و در این کانفیگ بر اساس interval عملیات فلاش صورت می گیرد.total_limit_size حداکثر حجم بافر را تعیین می کند.pathمحل ذخیره سازی chunk ها می باشد.retry_foreverبرای ارسال chunk مشخص می کند که بعد از به خطا خوردن تا ابد تلاش کند یا خیر.retry_typeنوع افزایش زمان انتظار بعد از هر تلاش ناموفق را مشخص می کند که در این قسمت به صورت نمایی انتخاب شده است.retry_exponential_backoff_baseعدد پایه نمودار نمایی برای افزایش زمان انتظار می باشد در این تنظیمات ۲ قرار داده شده است.retry_max_intervalحداکثر زمان انتظار را معیین می کند که در اینجا بیشتر از ۱ ساعت نمی شود.flush_thread_countتعداد فلاش های موازی را معین می کند.flush_intervalمدت زمان بین هر فلاش را تعیین می کند. @type prometheus port {{ .Values.metrics.service.port }} # input plugin that collects metrics from MonitorAgent @type prometheus_monitor host ${hostname} # input plugin that collects metrics for output plugin @type prometheus_output_monitor host ${hostname} # input plugin that collects metrics for in_tail plugin @type prometheus_tail_monitor host ${hostname} @type prometheus name fluentd_input_status_num_records_total type counter desc The total number of incoming records tag ${tag} hostname ${hostname} در تنظیمات این بخش متریک های مورد نیاز برای مانیتورینگ مقدار ورودی خروجی و بافر و ... fluentd استفاده می شودlabelsاین مقدار برای تعیین برچسب های متریک ها برای جدا سازی آن ها می باشد. (به عنوان مثال با تعیین tag به عنوان برچسب می توان فهمید هر برنامه چه تعداد لاگ ورودی دارد)در بخش دوم کانفیگ aggregator مورد بررسی قرار می گیرد.

راه اندازی Prometheus Aalert Manager

عرفان جعفری زمان — Thu, 07 Jul 2022 16:15:27 +0430

برای مدیریت اخطار ها در Prometheus از AlertManager استفاده می شود به طوری که اخطار ها را از سمت پرومتئوس می گیرد و کاربر نهایی را از طریق E-mail ، اسلک یا دیگر ابزارها مطلع می سازد. اخطار دهی منجر به این می شود همین که خطایی رخ داد، کاربر از آن مطلع شود.برای راه اندازی alertmanager به prometheus rule و کانفیگ خود alertmanager نیاز داریم. ابتدا با prometheus rule شرایط ایجاد خطا را مشخص می کنیم که نمونه کانفیگ آن در زیر آورده شده است:apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: mpaas labels: role: alert-rules spec: groups: - name: mpaas rules: - alert: example annotations: annotation1: example1 annotation2: example2 expr: sum(container_cpu_usage_seconds_total{namespace="cdn-prod"})>0 for: 5m labels: label1: example1 label2: example2در تنظیمات بالا قسمت های مهم به صورت زیر پیکربندی می شوند:annotationsبرای این که هنگام ارسال هشدار توضیحاتی برای مشخص شدن مشکل وجود داشته باشد از این قسمت استفاده می شود و بهتر است محل وقوع خطا و شدت خطا و ... آورده شود.exprکویری پرومتئوسی که برای تشخیص خطا به کار می رود.forمدت زمانی که خطا وجود داشته باشد تا هشدار به وجود بیاید.labelsبرای جدا کردن الرت ها از همدیگر زمان ارسال هشدار استفاده می شود برای مثال هشدار با label1: example1 به کاربر ۱ ارسال گردد.بعد از تمام شدن کانفیگ prometheus rule با استفاده از kubectl apply -n namespace prometheus-rule.yamlریسورس آن ایجاد می شود.حالا باید برای ارسال هشدار به کاربر alertmanager را پیکریندی کنیم:config: global: resolve_timeout: 1m route: receiver: 'default-team' group_wait: 30s group_interval: 30s repeat_interval: 1d group_by: [alertname] routes: - receiver: 'team1' group_wait: 10s group_interval: 5m repeat_interval: 4h group_by: [alertname] matchers: - label1=~"example1|example2" active_time_intervals: - offhours - holidays mute_time_intervals: - offhours - holidays continue: true receivers: - name: 'team1' webhook_configs: - url: http://example.com send_resolved: true - name: 'email' email_configs: - to: 'to@gmail.com' from: 'from@gmail.com' smarthost: smtp.gmail.com:587 auth_username: 'from@gmail.com' auth_identity: 'from@gmail.com' auth_password: 'pass' در کانفیگ بالا route مشخص می کند که هشدار ها با label های مختلف به کدام کاربر ارسال شوند هر کانفیگی که زیر مجموعه route و بالای routes باشد به عنوان تنظیمات پیش فرض انتخاب می شود و در قسمت routes می توان آن ها را overwrite کرد.group_waitمدت زمانی که الرت منیجر بعد از ایجاد هشدار صبر می کند و سپس هشدار را وارد گروه مشخص شده می کند.group_intervalاگر هشدار قبلا در گروه وجود داشته مدت زمانی که الرت منیجر بعد از ایجاد هشدار صبر می کند و سپس هشدار را وارد گروه مشخض شده می کند.repeat_intervalاگر هشدار برطرف نشده باشد بعد از این مدت زمان دوباره پیام را ارسال می شود.matchersدر زمان تعریف prometheus rule لیبل هایی برای alert ها می شخص می شوند با استفاده از این لیبل ها می توان تعیین کرد به receiver مورد نظر کدام هشدار ارسال شود.active_time_intervalsزمان هایی که ارسال هشدار فعال است را مشخص می کند.mute_time_intervalsزمان هایی که ارسال هشدار غیر فعال است را مشخص می کند.continueتعیین می کند اگر هشدار با receiver اول مطابق شده و هشدار ارسال شد ایا receiver بعدی نیز چک شود.حال باید receivers تنظیم شوند برای این ها انواع مختلفی وجود دارد که در اینجا دو حالت email و webhook مورد بررسی قرار گرفته است. به عنوان مثال برای کانفیگ Gmail باید اکانت مورد نظر به صورت لاگین دو مرحله ای باشد و از قسمت security > signing whit google مقدار password را کپی کرده و در auth_password قرار دهید. برای راه اندازی سرویس ارسال پیامک با استفاده از webhook باید یک fast api راه اندازی شده و درخواست را از alertmanager گرفته و به سمت سرویس ارسال پیامک ارسال کند و در درخواستی که به سمت fast api ارسال می گردد شماره تلفن به صورت query parameter به صورت زیر داده شود:url: http://example.com/?phone=09*********همچین فایل python مورد نیاز برای ارسال درخواست به صورت زیر نوشته می شود:from ctypes import Union from lib2to3.pgen2 import grammar from lib2to3.pgen2.token import NEWLINE from typing import Optional, Type from fastapi import FastAPI, Query from pydantic import BaseModel import requests from urllib.parse import unquote import urllib.parse import json class Book(BaseModel): version: str #... app = FastAPI() @app.post("/") def req(phone: str,annotations: Annotations): return_list=[] return_list.append(f"alertname : {annotations.alerts[0].get('labels').get('alertname')}") #... temp = "" nl= '\n' temp = f"{nl.join(return_list)}" uri = urllib.parse.quote(temp) url = "https://example?username=user&password=pass&from=from&to=" + phone + "&text=" + uri payload={} headers = { 'example': 'example' } response = requests.request("GET", url, headers=headers, data=payload)در کد بالا درخواست از سمت alertmanager ارسال می گردد و مقادیر مورد نیاز response body از آن با استفاده از Base model استخراج می شود به عنوان نمونه:version: str ...نمونه response body:{ "version": "4", "groupKey": , // key identifying the group of alerts (e.g. to deduplicate) "truncatedAlerts": , // how many alerts have been truncated due to "max_alerts" "status": "", "receiver": , "groupLabels": , "commonLabels": , "commonAnnotations": , "externalURL": , // backlink to the Alertmanager. "alerts": [ { "status": "", "labels": , "annotations": , "startsAt": "", "endsAt": "", "generatorURL": , // identifies the entity that caused the alert "fingerprint": // fingerprint to identify the alert }, ... ] }باید در هنگام راه اندازی fast apj مقدار response body الرت منیجر مشاهده شده و بر اساس آن Base mode تعریف شود.در قسمت return_list مقادیر مورد استخراج شده و به لیست خروجی که به صورت query parameter هست اضافه می شوندو در اخر براساس سرویس پیامک موجود url ساخته شده و مقادیر user و pass و ... در آن قرار می گیرد و با استفاده از‌ آن یک درخواست get به سمت سرویس پیامکی ارسال می شود

راه اندازی elasticsearch در kubernetes

عرفان جعفری زمان — Thu, 07 Jul 2022 11:23:57 +0430

الاستیک سرچ (Elasticsearch)، یک موتور جستجوی اوپن سورس است که توسط شرکت آپاچی و بر اساس Apache Lucene ساخته شده است. مبنای الاستیک سرچ، معماری Rest است.برای راه اندازی الستیک سرچ در kubernetes از راه های مختلفی میشه استفاده کرد از جمله eck operator, helm و ... که در این مقاله از روش eck operator استفاده شده.حالا eck operator چیه manager الستیک سرچ هست که برای راه اندازی الستیک مورد استفاده قرار می گیره یعنی ما فقط eck را رو تو یک namespace بالا می یاریم و کانفیگ الستیک رو براش ارسال می کنیم و شروع به راه اندازی الستیک می کنه.برای راه اندازی eck مراحل زیر رو طی می کنیم:با استفاده از دستور زیر برای کوبرنتیز custom resource های مرتبط با الستیک ایجاد می شود:kubectl create -f https://download.elastic.co/downloads/eck/2.2.0/crds.yamlبعد نوبت نصب operator فرا می رسد:kubectl apply -f https://download.elastic.co/downloads/eck/2.2.0/operator.yamlکه namespace پیش فرض آن elastic-system می باشدحالا فقط کافیه به صورت زیر کانفیگ الستیک رو با استفاده از kubectl به سمت کوبرنتیز ارسال کنیمcat <