🎸 🦂 🔖 PostgreSQL लॉग में त्रुटियों और घटनाओं की निगरानी करना (grok

शुभ दोपहर, सहकर्मियों और हेब्रचिकी! आज, मैं आपके साथ एक छोटा सा नोट साझा करना चाहता हूं कि आप प्रोमेथियस और मेट्रिक्स grok_exporter के निर्यातक का उपयोग करके PostgreSQL लॉग में दिखाई देने वाली त्रुटियों और घटनाओं के संचालन की निगरानी कैसे कर सकते हैं।

मुझे तुरंत कहना होगा कि यह निश्चित रूप से इस निर्यातक का उपयोग करने का एक विशेष मामला है। तो इसकी आवश्यकता क्यों है और किसे रुचि हो सकती है?

परिचय

इसकी जरूरत किसे है?

यदि प्रोमेथियस पहले से ही आपके बुनियादी ढांचे में मौजूद है और लॉग को इकट्ठा करने और विश्लेषण करने के लिए एक अलग बुनियादी ढांचा बनाना, जैसे कि ईएलके या ग्रेग्लोग, महंगा और अव्यवहारिक है (अगर कोई प्रोमेथियस नहीं है, तो यह कोई समस्या नहीं है, यह आसान और त्वरित रूप से स्थापित है)।

यह टूल न केवल डीबीए के लिए उपयोगी होगा, बल्कि एप्लीकेशन एडमिनिस्ट्रेटर के लिए भी, सामान्य तौर पर, उन सभी के लिए जो किसी तरह से एप्लीकेशन लॉग के साथ काम करते हैं। यह आपको स्वतंत्र रूप से व्यवहार के बारे में जानकारी प्राप्त करने की अनुमति देता है और स्थिति के आगे के विश्लेषण के लिए एक निश्चित संदर्भ बिंदु है।

यह सब किस लिए है?

निगरानी लॉग आपको अधिक संपूर्ण चित्र रखने और उभरती समस्याओं के लिए अधिक तेज़ी से प्रतिक्रिया करने की अनुमति देगा, यह हो: प्राधिकरण के प्रयास (असफल लोगों सहित), विभिन्न त्रुटियां, या विशिष्ट घटनाएं।

यहां एक अच्छी सूची है, जो इवेंट श्रेणियों (लॉग इवेंट श्रेणियाँ देखें अनुभाग) द्वारा बनाई गई है, इसका उपयोग प्रोमेथियस में नियम बनाने के लिए किया जा सकता है।

grok_exporter

मीट्रिक निर्यातक grok_exporter आपको स्रोत से असंरचित डेटा को पढ़ने की अनुमति देता है, इसे संरचित डेटा में परिवर्तित करता है, नियमों के अनुसार, और इसे एक प्रारूप में मैट्रिक्स के रूप में वापस करता है जिसे प्रोमेथियस समझता है।

निर्यातक एक प्लग-इन ईएलके प्लगइन्स-फिल्टर-ग्रॉक की छवि में बनाया गया था , जो आपको प्लगइन्स-फिल्टर-ग्रो टेम्प्लेट के एक सेट का उपयोग करने की अनुमति देता है जैसे वे हैं।

स्थापना

स्थापना सरल और सरल है। ऐसा करने के लिए, बस लिंक का अनुसरण करें और आपके द्वारा पसंद किए गए संस्करण को डाउनलोड करें (और हाँ वे सभी पूर्व-रिलीज़ हैं, और नवीनतम संस्करण अभी भी रिलीज़ उम्मीदवार चरण में हैं) और परिणामी संग्रह को अनज़िप करें।

परिणामस्वरूप, हमें निम्नलिखित सेट मिलते हैं:

grok_exporter-1.0.0.RC3.linux-amd64
├── patterns
│   ├── ruby
│   ├── redis
│   ├── rails
│   ├── postgresql
│   ├── nagios
│   ├── mongodb
│   ├── mcollective-patterns
│   ├── mcollective
│   ├── linux-syslog
│   ├── junos
│   ├── java
│   ├── haproxy
│   ├── grok-patterns
│   ├── firewalls
│   ├── exim
│   ├── bro
│   ├── bacula
│   └── aws
├── grok_exporter
└── example
    ├── exim-rejected-RCPT-examples.log
    ├── config.yml
    └── config_logstash_http_input_ipv6.yml

कहाँ पे:

grok_exporter - निर्यातक निष्पादन योग्य
पैटर्न - पैटर्न का एक सेट होता है
उदाहरण - एक परीक्षण डेटा सेट और एक उदाहरण कॉन्फ़िगरेशन फ़ाइल शामिल है

निर्यातक को शुरू करने के लिए, बस निष्पादन योग्य फ़ाइल चलाएं। Config.yml कॉन्फ़िगरेशन फ़ाइल उस निर्देशिका में खोजी जाती है जहाँ से एप्लिकेशन लॉन्च किया गया है या इसका स्थान -config विकल्प द्वारा निर्दिष्ट किया गया है

काम के लिए सेटअप और तैयारी

PostgreSQL

, PostgreSQL. :

grok_exporter . , pg_reload_conf.

alter system set log_directory to '/var/log/postgresql';

alter system set log_file_mode to '0644';

log_line_prefix, . , . :

 alter system set log_line_prefix to '%t datname:%d,client:%h,app:%a,usename:%u,session:%c ';

grok_exporter

सबसे पहले, हम अपनी लॉग फ़ाइल के प्रारूप के अनुसार पैटर्न / पोस्टग्रैस्कल टेम्पलेट को संपादित करेंगे और सहायक निर्माणों को जोड़ेंगे। मैं एक बार फिर इस बात पर जोर देता हूं कि टेम्प्लेट का सिंटैक्स पूरी तरह से संगत है जो कि प्लग-फिल्टर-ग्रॉक में उपयोग किया जाता है , इसलिए, सिंटैक्स से संबंधित सभी मुद्दों के लिए, आपको इसके प्रलेखन पर जाना चाहिए। तो, चलिए PostgreSQL के लिए हमारे टेम्प्लेट को फॉर्म में लाते हैं ( पैटर्न / ग्रॉक-पैटर्न फ़ाइल में पहले से ही बेसिक टेम्पलेट का एक बड़ा सेट शामिल है:

#     - postgresql
PG_TIMESTAMP %{YEAR}-%{MONTHNUM}-%{MONTHDAY} %{HOUR}:%{MINUTE}:%{SECOND} [A-Z]{3,4}

#    
PG_ERROR_PATTERN (ERROR|WARNING|FATAL|PANIC)

# log_line_prefix   - PostgreSQL
PG_PREFIX %{PG_TIMESTAMP} datname:(%{DATA:datname})?,client:(%{DATA:client_host})?,app:(%{DATA:app_name})?,usename:(%{USER:usename})?,session:(%{DATA:session})?

#    log_level     
PG_ERROR_LEVEL %{PG_ERROR_PATTERN:log_level}:

#    
PG_EVENT_AUTH LOG:  connection authorized:

#      SIGHUP,   
PG_EVENT_RELOAD LOG:  received SIGHUP, reloading configuration files

डिज़ाइन ()?आपको यह इंगित करने की अनुमति देता है कि मूल्य वैकल्पिक है।

यहां, पर्याप्त विवरण में, उदाहरणों के साथ, कॉन्फ़िगरेशन फ़ाइल बनाने की प्रक्रिया का वर्णन किया गया है। नीचे, केवल वही उपयोग किया जाएगा जो दिया गया है।

कॉन्फ़िगरेशन फ़ाइल का संक्षिप्त विवरण (प्रलेखन से)

YAML :

global —
- config_version — . grok_exporter, ≥ 1.0.0.RC3, 3
  retention_check_interval — . , .
input — .
- type — . : file, stdin, webhook. , file;
- path|paths — c -(-). ;
- readall — , .
  true — , . Prometheus .
  false — , grok_exporter;
- fail_on_missing_logfile — -. true — , ;
imports — , , . 2, , grok.
- type — grok_patterns () metrics ();
- file|dir — . , .
grok_patterns — , .
metrics — . — counter, gauge, histogram, or summary.

server —

  protocol: https
  host: localhost
  port: 9144
  path: /metrics
  cert: /path/to/cert
  key: /path/to/key

कॉन्फ़िगरेशन फ़ाइल के 3 संस्करण के सिंटैक्स में, व्यक्तिगत फ़ाइलों से मैट्रिक्स आयात करना संभव हो गया, यह आपको उद्देश्य से समूह मैट्रिक्स करने की अनुमति देगा।

अगला, आधार config.yml कॉन्फ़िगरेशन फ़ाइल बनाएँ । इसमें, हम: मास्क द्वारा पोस्टग्रेक्यूएल लॉग फाइलों के लिए पथ सेट करें; मेट्रिक्स. d निर्देशिका से पैटर्न निर्देशिका और मैट्रिक्स से आयात टेम्पलेट्स ; हम संकेत देते हैं कि किस प्रोटोकॉल और किस पोर्ट पर मैट्रिक्स के लिए आवेदन करना आवश्यक है।

config.yml

  config_version: 3
  retention_check_interval: 10s
input:
  type: file
  path: /var/log/postgresql/postgresql-*.log
  readall: false
imports:
- type: grok_patterns
  dir: ./patterns
- type: metrics
  dir: ./metrics.d
server:
  protocol: http
  port: 9144

, metrics.d postgresql.yml, .

, , .. ( retention, - 2 30 ) , . retention_check_interval.

, :

, ;
— GAUGE COUNTER, . .. GAUGE, ;
यदि संचयी को सही पर सेट किया जाता है, तो एक ही सेट के साथ मेट्रिक्स के मान सम्‍मिलित होंगे, जो अपेक्षित व्यवहार है। एक अप्रत्याशित स्थिति उत्पन्न हो सकती है, जब दूसरे अनुरोध पर, आप अनुरोध में मानों का योग और पिछले मूल्य प्राप्त कर सकते हैं।
यदि संचयी को झूठा सेट किया जाता है, यदि लेबल के समान सेट के साथ मैट्रिक्स हैं, तो केवल अंतिम मान प्रदर्शित किया जाएगा;

इसने बहुत सी चिट्ठियों को उलझाया, भ्रामक और अयोग्य स्थानों में, लेकिन मैं नीचे दिए गए उदाहरणों में इसका खुलासा करने की कोशिश करूंगा।

और इसलिए, हमारे पास एक कॉन्फ़िगरेशन फ़ाइल है जो चार मैट्रिक्स, तीन काउंटर और एक मनमाना मूल्य वापस कर सकती है। वास्तव में, पहले तीन स्रोत से प्राप्त तार के साथ मैच टेम्पलेट क्षेत्र के मैचों की संख्या पर विचार करते हैं, चौथा - मूल्यों का योग प्रदर्शित करता है।

postgresql.yaml

#  - 
- type:   counter
  name:   pg_grok_error_count
  help:   Count of line error
  match:  '%{PG_PREFIX} %{PG_ERROR_LEVEL}  %{GREEDYDATA:message}'
  labels:
    log_level:   '{{.log_level}}'
    usename:     '{{.usename}}'
    datname:     '{{.datname}}'
    app_name:    '{{.app_name}}'
    client_host: '{{.client_host}}'
    message:     '{{.message}}'

#   
- type:   counter
  name:   pg_grok_auth_succes_count
  help:   Count of connections authorized
  match:  '%{PG_PREFIX} %{PG_EVENT_AUTH}'
  labels:
    usename:     '{{.usename}}'
    datname:     '{{.datname}}'
    app_name:    '{{.app_name}}'
    client_host: '{{.client_host}}'

#   
- type:   counter
  name:   pg_grok_reload_conf_count
  help:   Count of call pg_reload_conf
  match:  '%{PG_PREFIX} %{PG_EVENT_RELOAD}'
  labels:
    session:     '{{.session}}'

#   
- type:       gauge
  name:       pg_grok_tpm_file_size_bytes
  help:       Size of tmp file created by time
  match:      '%{PG_PREFIX} %{PG_EVENT_TMP_FILE}'
  value:      '{{.size}}'
  cumulative: true
  retention:  5s
  labels:
    static:     'temp_file'

अभ्यास

pg_grok_error_count

मीट्रिक पैटर्न के अनुसार ईआरओआरओआर, वार्निंग, फेटल और पैनआईसी की घटनाओं की संख्या को गिनाता है। यह आपातकाल के मामले में निगरानी और चेतावनी के लिए उपयोगी हो सकता है। उदाहरण के लिए, आप निम्न मामलों में अलर्ट कॉन्फ़िगर कर सकते हैं: असफल प्राधिकरण का प्रयास, समय की प्रति यूनिट त्रुटियों की सीमा से अधिक, या जब डेटाबेस विफलता के बाद पुनर्प्राप्ति स्थिति में होता है, और बहुत अधिक ( लॉग इवेंट श्रेणियाँ )।

उदाहरण के लिए, हम असफल प्राधिकरण प्रयासों के बारे में अलर्ट सेट करेंगे। PostgreSQL लॉग फ़ाइल में असफल लॉगिन प्रयास का एक उदाहरण इस प्रकार है:

2020-04-20 23:34:53 AEST datname:test,client:127.0.0.1,app:[unknown],usename:test_user,session:5e9da4fd.733 FATAL:  password authentication failed for user "test_user"
2020-04-20 23:34:53 AEST datname:test,client:127.0.0.1,app:[unknown],usename:test_user,session:5e9da4fd.733 DETAIL:  Password does not match for user "test_user".
        Connection matched pg_hba.conf line 86: "host    all             all             127.0.0.1/32            md5"

Grok_exporter के उत्पादन में, विफल रही है प्रमाणीकरण प्रयास से पहचाना जा सकता संदेश लेबल -स्ट्रिंग युक्त पासवर्ड प्रमाणन के लिए ... में विफल रहा है :

pg_grok_error_count{app_name="[unknown]",client_host="127.0.0.1",datname="postgres",log_level="FATAL",message="password authentication failed for user "postgres"", usename="postgres"} 15
pg_grok_error_count{app_name="[unknown]",client_host="127.0.0.1",datname="test",log_level="FATAL",message="password authentication failed for user \"test_user\"",usename="test_user"} 5

प्राप्त डेटा प्रोमेथियस के लिए एक नियम बनाने में मदद करेगा। संवेदनशीलता को अपनी वास्तविकताओं के आधार पर समायोजित किया जा सकता है।

groups:
- name: AuthAlert
  rules:
  - alert: AuthFail
    expr: sum(rate(pg_grok_error_count{message=~"password authentication failed for user.*"}[1m])) by (instance) > 0.1
    for: 30s
    labels:
      severity: warning
    annotations:
      summary: Too many fail authorization for {{ $labels.instance }}

pg_grok_reload_conf_count

इसी तरह, आप pg_reload_conf कमांड के निष्पादन को ट्रैक कर सकते हैं। इसके अलावा, यह लेबल की सूची पर ध्यान देने योग्य है, या यों कहें कि केवल एक सत्र लेबल का उपयोग किया जाता है। यह इस तथ्य के कारण है कि ईवेंट को सर्वर प्रक्रिया के हिस्से के रूप में बनाया गया है, न कि उपयोगकर्ता सत्र।

PostgreSQL लॉग फ़ाइल में, यह ईवेंट इस तरह दिखता है:

2020-04-21 01:20:26 AEST datname:,client:,app:,usename:,session:5e9d9371.564 LOG:  received SIGHUP, reloading configuration files

उन। यह देखा जा सकता है कि पिछले उदाहरण में उपयोग किए गए लेबल खाली हैं। इस स्थिति में, हम पहचान के लिए सत्र पहचानकर्ता का उपयोग करेंगे, और यह तब तक नहीं बदलेगा जब तक कि PostgreSQL का उदाहरण बंद या फिर से शुरू नहीं हो जाता।

इसी तरह की स्थिति अन्य समान मामलों के लिए होगी, उदाहरण के लिए, एक उदाहरण को रोकना:

2020-04-21 01:32:52 AEST datname:,client:,app:,usename:,session:5e9d9371.564 LOG:  received fast shutdown request
2020-04-21 01:32:53 AEST datname:,client:,app:,usename:,session:5e9d9371.564 LOG:  database system is shut down

Grok_exporter के उत्पादन में, हम प्राप्त करते हैं:

# HELP pg_grok_reload_conf_count Count of call pg_reload_conf
# TYPE pg_grok_reload_conf_count counter
pg_grok_reload_conf_count{session="5e9d9371.564"} 5

अधिसूचना के लिए नियम, इसे लाने का कोई मतलब नहीं है, यह ऊपर चर्चा की गई के समान होगा।

pg_grok_tpm_file_size_bytes

तुरंत एक आरक्षण करें कि यह उदाहरण "एक निर्वात में गोलाकार घोड़े" की श्रेणी से है और यह दिखाने के लिए कि आप मेट्रिक्स के व्यवहार को कैसे बदल सकते हैं, यह अधिक हद तक दिया जाता है। गेज मेट्रिक्स

का व्यवहार प्रतिधारण और संचयी मापदंडों को बदलकर प्रभावित किया जा सकता है । वास्तव में, एक नियमित काउंटर के विपरीत, जो मैच पैटर्न से मेल खाती लाइनों की संख्या पर विचार करता है, गेज आपको लॉग फ़ाइल से डेटा पर काम करने की अनुमति देता है। यह पता चला है कि हम इसे प्राप्त मूल्य से बढ़ाकर या घटाकर जमा कर सकते हैं, या इसे मनमाने ढंग से बदलते मूल्य के रूप में उपयोग कर सकते हैं। इस प्रकार, पहले मामले में, हम वेतन वृद्धि के परिमाण में दिलचस्पी लेंगे, दूसरे में - अपने आप में मूल्य। आइए कुछ उदाहरण देखें:

, (cumulative: true). , , . , retention_check_interval + retention <= scrape_interval — Prometheus.

- PostgreSQL :

2020-04-21 02:51:15 AEST datname:,client:,app:,usename:,session:5e9dd2f3.1278 LOG:  temporary file: path "base/pgsql_tmp/pgsql_tmp4728.0", size 46931968
2020-04-21 02:51:15 AEST datname:,client:,app:,usename:,session:5e9dd2f3.1279 LOG:  temporary file: path "base/pgsql_tmp/pgsql_tmp4729.0", size 46276608
2020-04-21 02:51:15 AEST datname:postgres,client:[local],app:psql,usename:postgres,session:5e9dc0a8.112c LOG:  temporary file: path "base/pgsql_tmp/pgsql_tmp4396.14", size 47194112

, :

pg_grok_tpm_file_size_bytes{static="temp_file"} 1.40402688e+08

.

, :

pg_grok_tpm_file_size_bytes{static="temp_file"} 1.1911168e+07

: , .

, , (retention) (cumulative: true)
, - PostgreSQL :

2020-04-21 03:03:40 AEST datname:,client:,app:,usename:,session:5e9dd5dc.12c6 LOG:  temporary file: path "base/pgsql_tmp/pgsql_tmp4806.0", size 46260224
2020-04-21 03:03:40 AEST datname:,client:,app:,usename:,session:5e9dd5dc.12c5 LOG:  temporary file: path "base/pgsql_tmp/pgsql_tmp4805.0", size 46833664
2020-04-21 03:03:40 AEST datname:postgres,client:[local],app:psql,usename:postgres,session:5e9dc0a8.112c LOG:  temporary file: path "base/pgsql_tmp/pgsql_tmp4396.15", size 47316992

pg_grok_tpm_file_size_bytes{static="temp_file"} 1.40402688e+08

, . :

2020-04-21 03:10:40 AEST datname:,client:,app:,usename:,session:5e9dd76e.1325 LOG:  temporary file: path "base/pgsql_tmp/pgsql_tmp4901.0", size 46776320
2020-04-21 03:10:40 AEST datname:,client:,app:,usename:,session:5e9dd76e.1324 LOG:  temporary file: path "base/pgsql_tmp/pgsql_tmp4900.0", size 45768704
2020-04-21 03:10:40 AEST datname:postgres,client:[local],app:psql,usename:postgres,session:5e9dc0a8.112c LOG:  temporary file: path "base/pgsql_tmp/pgsql_tmp4396.18", size 47841280

pg_grok_tpm_file_size_bytes{static="temp_file"} 2.80772608e+08

, . , .

, cumulative false , .

:

2020-04-21 03:41:04 AEST datname:,client:,app:,usename:,session:5e9ddea4.1393 LOG:  temporary file: path "base/pgsql_tmp/pgsql_tmp5011.0", size 11763712
2020-04-21 03:41:04 AEST datname:,client:,app:,usename:,session:5e9ddea4.1392 LOG:  temporary file: path "base/pgsql_tmp/pgsql_tmp5010.0", size 11501568
2020-04-21 03:41:04 AEST datname:postgres,client:[local],app:psql,usename:postgres,session:5e9dc0a8.112c LOG:  temporary file: path "base/pgsql_tmp/pgsql_tmp4396.19", size 11911168

# HELP pg_grok_tpm_file_size_bytes Size of tmp file created by time
# TYPE pg_grok_tpm_file_size_bytes gauge
pg_grok_tpm_file_size_bytes{static="temp_file"} 1.1911168e+07

, . , .

निस्संदेह grok_exporter अनुप्रयोगों की निगरानी के लिए सही उपकरण है। यह आपको मॉनिटरिंग सिस्टम, स्थानों और अतिरिक्त (नियंत्रण) मेट्रिक्स के साथ निगरानी को समृद्ध बनाने के लिए "एक्सेस करने में मुश्किल" देखने की अनुमति देता है, जबकि काफी सरल, कार्यात्मक और हल्के रहते हैं।

उसी समय, यह डेवलपर्स के लिए भी उपयोगी होगा, क्योंकि यह मॉनिटरिंग सिस्टम के माध्यम से कम से कम अप्रत्यक्ष रूप से एप्लिकेशन लॉग को एक्सेस करता है। जहां आप विभिन्न स्रोतों से मैट्रिक्स को सहसंबंधित कर सकते हैं।

एक और सकारात्मक बिंदु यह है कि परियोजना विकसित हो रही है और नई कार्यक्षमता प्राप्त कर रही है।

बदले में, मुझे उम्मीद है कि यह लघु नोट उपयोगी होगा, जिसमें परियोजना भी शामिल है। अधिक सितारे, अधिक मज़ेदार काम!

सभी को धन्यवाद!

PostgreSQL लॉग में त्रुटियों और घटनाओं की निगरानी करना (grok_exporter)

परिचय

इसकी जरूरत किसे है?

यह सब किस लिए है?

grok_exporter

स्थापना

काम के लिए सेटअप और तैयारी

PostgreSQL

grok_exporter

अभ्यास

pg_grok_error_count

pg_grok_reload_conf_count

pg_grok_tpm_file_size_bytes

More articles: