प्रोमेथियस प्रारूप में आंकड़े निर्यात करने के लिए सिम्फनी बंडल

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

इस पूरी अर्थव्यवस्था को एक अलग बंडल में विभाजित करने का निर्णय लिया गया: ArtprimaPrometheusMetricsBundle ।

सभी अनुप्रयोगों के लिए सामान्य मीट्रिक चुनना, मैंने एक बंडल लिखने के बारे में निर्धारित किया है। क्लाइंट को जिम्डो / prometheus_client_php क्लाइंट के रूप में चुना गया था, जो आपको एक सांख्यिकी स्टोर के रूप में उपयोग करने की अनुमति देता है: Redis (ext-redis के माध्यम से), APCu (ext-apcu के माध्यम से) और InMemory (PHP मेमोरी में, केवल प्रक्रिया के जीवन के लिए)। मैं तुरंत एक आरक्षण कर दूंगा कि केवल एपीसीयू का व्यवहार में परीक्षण किया जाता है (मुझे प्रति-उदाहरण आँकड़े की आवश्यकता है, जबकि रेडिस में साझा किए जाएंगे, जब तक कि रेडिस प्रत्येक उदाहरण के लिए तैनात न हो)। और आम तौर पर इनमेमोरी, आईएमएचओ, केवल परीक्षणों के लिए उपयोग किया जा सकता है।

जिम्डो / prometheus_client_php के साथ तुरंत एक समस्या थी - लंबे समय तक कोई रिलीज़ नहीं हुई थी, और आवश्यक सुविधाएँ (APCu) रिलीज़ के रूप में उपलब्ध नहीं हैं। इस संबंध में, मैंने अपने ग्राहक का कांटा बनाया, जो केवल इस बात में भिन्न है कि इसमें रिलीज को उत्पन्न करने के लिए सही टैग है।

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

दरअसल, आपको मुख्य कॉन्फ़िगरेशन को कॉन्फ़िगर करने की आवश्यकता है:

#config/packages/prometheus-metrics.yaml artprima_prometheus_metrics: # namespace     prometheus namespace: myapp #    type: in_memory #  : in_memory, apcu, redis #   ,         ignored_routes: [some_route_name, another_route_name] #     "redis" (   ) redis: host: 127.0.0.1 port: 6379 timeout: 0.1 read_timeout: 10 persistent_connections: false password: ~ 

फिर आपको मार्ग निर्यात करने की आवश्यकता है:

 #    /metrics/prometheus app_metrics: resource: '@ArtprimaPrometheusMetricsBundle/Resources/config/routing.xml' 

या आप मार्ग को मैन्युअल रूप से कॉन्फ़िगर कर सकते हैं:

 app_metrics: path: /mypath/mymetrics controller: Artprima\PrometheusMetricsBundle\Controller\MetricsController::prometheus 

हो गया। परिणामस्वरूप, आपके मैट्रिक्स http [s]: // your_host / metrics / prometheus पर उपलब्ध होंगे (यदि आपने पथ नहीं बदला है)। और कुछ समय बाद आपको कुछ ऐसा मिलता है:


स्वाभाविक रूप से, जल्द ही पर्याप्त बुनियादी मैट्रिक्स नहीं हो सकते हैं, इसलिए आपके पास हमेशा अपना खुद का मीट्रिक जनरेटर (मौजूदा एक के अलावा) लिखने और इसे इस तरह निर्यात करने का अवसर होता है:

 # config/services.yaml App\Metrics\MyMetricsGenerator: tags: - { name: prometheus_metrics_bundle.metrics_generator } 

उसी समय, आपके जनरेटर को Artprima\PrometheusMetricsBundle\Metrics\MetricsGeneratorInterface लागू करना होगा। आप देख सकते हैं कि Artprima\PrometheusMetricsBundle\Metrics\AppMetrics में जनरेटर कैसा दिख सकता है। यहां आपको जो मुख्य बात जानने की जरूरत है वह यह है कि collectRequest मेथड collectRequest kernel.request ईवेंट पर कहा जाता है, और collectResponse मेथड को kernel.terminate इवेंट पर collectResponse ।

मैं आलोचना को संक्षेप में स्वीकार करता हूं। युक्तियाँ और PR :-) के रूप में दोनों

पुनश्च ने टिप्पणी की कि हमने बाइक का आविष्कार किया है: हां, मुझे पता है कि विकल्प हैं। और, सबसे अधिक संभावना है, वे निश्चित रूप से बेहतर हैं। विशेष रूप से, उनमें से एक TweedeGolfPrometheusBundle है । दुर्भाग्य से, मुझे यह याद नहीं है कि हमने यह समाधान क्यों नहीं चुना, लेकिन छह महीने से कुछ अधिक समय पहले हमने इसे आजमाया और इससे इनकार कर दिया। एक तरीका या दूसरा, मेरा मानना ​​है कि चुनाव करना हमेशा अच्छा होता है, यही वजह है कि हमारा बंडल ओपनसोर्स में प्रकाशित हुआ।