Следење на услугите на Голанг со Прометеј: Избор помеѓу моделите за влечење и туркање

Што е Прометеј и зошто ви е потребен?

Prometheus е моќен систем за следење кој собира и обработува нумерички податоци (метрика) од апликациите. Тоа ви помага да ги следите клучните индикатори како што се:

• Бројот на барања што ги обработува вашата услуга.
• Времето на одговор за секое барање.
• Употреба на меморија и процесор.
• Бројот на грешки што се појавуваат во системот.

Со користење на Прометеј, можете да одговорите на критични прашања како што се:

• „Дали мојата услуга работи ефикасно?

• „Кои се тесните грла на перформансите?

• „Дали треба да ја зголемиме нашата инфраструктура?

  
  

И како Прометеј собира метрика?

Постојат два основни начини на кои Прометеј собира податоци:

1. Модел на влечење - Прометеј активно ги бара услугите за нивните метрики.
2. Push модел (Pushgateway) – Услугите ги туркаат своите метрики до посредник, кој Prometheus потоа го собира.

Ајде да ги разбиеме.

Повлечете модел

Во моделот за повлекување , Прометеј активно презема метрики од вашата апликација преку HTTP (на пр. http://your-service:8080/metrics ).

Ова е стандардниот и најчесто користен метод.

Поставување на Prometheus со Golang (Pull Model)

1. Инсталирајте ги потребните библиотеки:

    go get github.com/prometheus/client_golang/prometheus go get github.com/prometheus/client_golang/prometheus/promhttp

   
   

2. Дефинирајте ја вашата метрика (на пр., броење HTTP барања):

    import ( "github.com/prometheus/client_golang/prometheus" "github.com/prometheus/client_golang/prometheus/promauto" ) var httpRequestsTotal = promauto.NewCounter(prometheus.CounterOpts{ Name: "http_requests_total", Help: "Total number of HTTP requests", })

   
   

3. Откријте крајна точка /metrics :

    import ( "net/http" "github.com/prometheus/client_golang/prometheus/promhttp" ) func main() { http.Handle("/metrics", promhttp.Handler()) }

   
   

4. Конфигурирајте го Prometheus да ги брише метриките од вашата услуга во prometheus.yml :

    scrape_configs: - job_name: "example_service" static_configs: - targets: ["localhost:8080"]

Сега, Prometheus автоматски ќе бара http://localhost:8080/metrics на секои неколку секунди за да собира податоци.

Зошто се претпочита моделот Pull?

• Едноставност - Прометеј го контролира распоредот и фреквенцијата на гребење.
• Помалку точки на неуспех - Нема потреба од дополнителна услуга за примање метрика.
• Автоматско чистење – Ако услугата престане да реагира, Prometheus едноставно престанува да прима податоци, избегнувајќи застоена метрика.

Push Model (Pushgateway Approach)

Во моделот push , услугата ги испраќа своите метрики до посредничка услуга наречена Pushgateway , која ги складира додека Прометеј не ги преземе.

Како функционира (Push Model)

1. Вашата апликација ги турка метриките до Pushgateway:

    import ( "github.com/prometheus/client_golang/prometheus" "github.com/prometheus/client_golang/prometheus/push" ) func main() { registry := prometheus.NewRegistry() jobCounter := prometheus.NewCounter(prometheus.CounterOpts{ Name: "job_execution_count", Help: "Number of executed jobs", }) registry.MustRegister(jobCounter) jobCounter.Inc() err := push.New("http://localhost:9090", "my_service_or_job"). Collector(jobCounter). Grouping("instance", "worker_1"). Push() if err != nil { panic(err) } }

   
   

2. Конфигурирајте го Prometheus да собира податоци од Pushgateway:

    scrape_configs: - job_name: "pushgateway" static_configs: - targets: ["localhost:9091"]

Кога моделот Push е всушност корисен?

• Краткотрајни работи (групни задачи, cron работни места) кои завршуваат пред Прометеј да може да ги изгребе.
• Мрежни ограничувања каде што Prometheus не може директно да пристапи до услугата.
• Надворешни извори на податоци (IoT уреди, надворешни API) кои не можат директно да се изгребат.

Кој модел треба да го користите?

Зошто Push Model не е идеален?

Иако Pushgateway решава некои проблеми (на пример, краткотрајните процеси кои завршуваат пред Прометеј да ги изгребе), тој воведува неколку нови проблеми :

1. Тешко е да се управуваат застарените податоци

   • Ако услугата изумре, нејзината стара метрика останува во Pushgateway.

   • Прометеј нема начин да знае дали услугата сè уште работи.

   • Мора рачно да ги избришете застарените метрики користејќи push.Delete(...) или да ги конфигурирате политиките за истекување.

     
     

2. Дополнителна сложеност

   • Наместо директна врска Service → Prometheus , сега имате Service → Pushgateway → Prometheus .

   • Pushgateway е дополнителна зависност, што ги зголемува трошоците за одржување.

     
     

3. Потенцијални тесни грла

   • Ако многу услуги често притискаат метрика, Pushgateway може да биде преоптоварен.

   • За разлика од директните гребење на Prometheus (кои го дистрибуираат товарот), сите барања погодуваат еден пример на Pushgateway.

     
     

4. Проблеми со конзистентноста на податоците
   • Ако повеќе услуги туркаат метрика со исто име, но различни вредности, податоците може да бидат препишани, што ќе доведе до неточни резултати.

Заклучок

Прометеј е моќна и сигурна алатка за следење на услугите. За повеќето апликации, моделот за повлекување е најдобриот избор - тој е едноставен, ефикасен и обезбедува свежи податоци без дополнителна сложеност. Меѓутоа, ако работите со краткотрајни процеси како што се функциите на Lambda или сериските задачи, моделот на push преку Pushgateway може да биде корисен за снимање на метрика пред да излезе процесот.

Изборот на вистинскиот пристап обезбедува подобра набљудуваност и одржување на вашиот систем.

Внимавајте!