আমি আমার প্রমিথিউস ডাটাবেসে হারিয়ে যাওয়া ডেটা কীভাবে সমস্যার সমাধান করব?

13

চলমান অবকাঠামো সম্পর্কে বিশদ মেট্রিক সংগ্রহ করতে আমি পর্যায়ক্রমে আমার পর্যবেক্ষণ কর্মপ্রবাহে প্রমিথিউসকে সংহত করছি inte

এই সময়ে, আমি লক্ষ করেছি যে আমি প্রায়শই একটি অদ্ভুত ইস্যুতে চলে যাই: কখনও কখনও এমন কোনও রফতানিকারক যে প্রমিথিউস থেকে ডেটা টানবেন বলে মনে করা হয় তা প্রতিক্রিয়াহীন হয়ে যায়। কোনও নেটওয়ার্কের ভুল কনফিগারেশনের কারণে - এটি আর অ্যাক্সেসযোগ্য নয় - বা কেবল রফতানিকারীর ক্রাশ হওয়ার কারণে।

এটি যে কারণেই হোক না কেন, আমি দেখতে পেয়েছি যে প্রমিথিউসে আমি যে ডেটা প্রত্যাশা করেছিলাম তার কিছু অনুপস্থিত এবং নির্দিষ্ট সময়ের জন্য সিরিজের কোনও কিছুই নেই। কখনও কখনও, একজন রফতানিকারীর ব্যর্থতা (সময় নির্ধারণ?) এছাড়াও অন্যকে ব্যর্থ করে তোলে বলে মনে হয় (প্রথম টাইমআউট পুরো কাজটি টপ-লেভেলের টাইমআউটের উপরে ফেলে দেয়? কেবল অনুমান করা হয়)।

উপরের ভিজ্যুয়ালাইজেশনে যেমন দেখানো হয়েছে তেমনই আমি সিরিজের একটি ফাঁক is লগতে এমন কিছু নেই যখন এটি ঘটে। প্রমিথিউস স্ব-মেট্রিকগুলিও মোটামুটি অনুর্বর বলে মনে হয়। প্রমিথিউস কী করছে এবং কোথায় তা ভেঙে গেছে তা দেখার জন্য আমাকে নিজেই পুনরায় চেষ্টা করতে হয়েছিল। এটা উদার। আরও ভাল উপায় থাকতে হবে! যদিও আমার রিয়েলটাইম সতর্কতাগুলির প্রয়োজন নেই, আমি কমপক্ষে এটি দেখতে সক্ষম হতে চাই যে একজন রফতানিকারক ডেটা সরবরাহ করতে ব্যর্থ হয়েছিল। এমনকি একটি বুলিয়ান "আরে আপনার ডেটা পরীক্ষা করুন" পতাকাটি শুরু হবে।

প্রমিথিউস রফতানিকারীদের কাছ থেকে ডেটা প্রাপ্ত করতে ব্যর্থ হওয়া সম্পর্কে আমি কীভাবে অর্থবহ তথ্য পেতে পারি? প্রমিথিউস ডেটা সংগ্রহের ম্যানুয়াল সিমুলেশন না করে ফাঁক কেন বিদ্যমান তা আমি কীভাবে বুঝতে পারি? এক্ষেত্রে বোধগম্য অনুশীলনগুলি কী কী, সম্ভবত প্রমিথিউসের বাইরেও সাধারণভাবে ডেটা সংগ্রহগুলি পর্যবেক্ষণ করার সময় বাড়ানো হলেও?

monitoring prometheus

— স্যান্ডার
সূত্র

আপনার সমস্যার সাথে সম্পর্কিত কোনও লগ এন্ট্রি বা সতর্কতা / ত্রুটি রয়েছে?

— কেনারব

যাই হোক না কেন, আমি কেবল ডেটা সিরিজের ফাঁক দেখছি see প্রমিথিউস আউটপুটটিতে প্রতি কয়েক মিনিটের মধ্যে মুলতুবি থাকা পরিবর্তনগুলি সংরক্ষণ করার বিষয়ে সাধারণ নিয়মিত লাইন রয়েছে এবং কী হবে না (যদি না আমি কিছু লুকানো লগগুলি লক্ষ্য না করি)।

— স্যান্ডার

আমরাও এই সমস্যার মুখোমুখি হই। @ স্যান্ডার আপনি কি কারণটি আবিষ্কার করতে পেরেছেন?

— দীপক এন

দুর্ভাগ্যক্রমে, দীদীপকন না, আমার এখানে যুক্ত করার কোনও কার্যকর অন্তর্দৃষ্টি নেই। প্রমিথিউস ব্যবহার করার সময় এটি একটি ব্যথার বিষয় হিসাবে রয়ে গেছে।

— স্যান্ডার

5

আমি মনে করি আপনি কোনও মেট্রিককে rateএই জাতীয় কিছু দিয়ে সতর্কতার কিছু করতে পারেন:

ALERT DropInMetricsFromExporter
  IF rate(<metric_name>[1m]) == 0
  FOR 3m
  ANNOTATIONS {
    summary = "Rate of metrics is 0 {{ $labels.<your_label> }}",
    description = "Rate of metric dropped, actually: {{ $value }}%",
}

মূল ধারণাটি হ'ল সতর্কতা অবলম্বন করা উচিত যখনই মেট্রিকের হারটি 3 মিনিটের জন্য 0 হয়, সঠিক মেট্রিকের নাম এবং কোনও লেবেল কোথাও কোথা থেকে আসে যে কোন রফতানিকারীর কাছ থেকে বলা হয় এটি আপনাকে সঠিক তথ্য দেওয়া উচিত।

রফতানিকারক দ্বারা নিরীক্ষণের জন্য ডান মেট্রিক নির্বাচন করা জটিল হতে পারে, আরও অন্তর্দৃষ্টি ছাড়াই শূন্যতার বাইরে আরও ভাল পরামর্শ দেওয়া কঠিন।
এই ব্লগ পোস্টটি আরও সাধারণ সনাক্তকরণের জন্য অনুপ্রেরণা হতে পারে।

— Tensibai
সূত্র

হার প্রদত্ত কাউন্টারটির জন্য প্রতি সেকেন্ডের হার গণনা করে। যে হারে মেট্রিকগুলি স্ক্র্যাপ করা হয় (-> স্ক্র্যাপ_ইন্টারভাল) তার সাথে এর কোনও সম্পর্ক নেই। প্রদত্ত কাউন্টার (মেট্রিক_নাম) যদি 3 মিনিটের জন্য না বাড়ায় তবে সম্ভবত ওপি যা চায় তা নয়, আপনার উদাহরণটি সতর্ক করবে।

— জোহানেস 'ফিশ' জিমকে

@ জোহানেস'ফিশ'জিমেক কেন আমি বললাম সঠিক মেট্রিক পাওয়া জটিল হতে পারে। timeউদাহরণস্বরূপ নোড রফতানিকারীতে মেট্রিক ব্যবহার করা do আপনার যদি কোনও রফতানিকারীর ব্যর্থতা সম্পর্কে সতর্ক করার আরও ভাল উপায় থাকে তবে একটি উত্তর যুক্ত করতে দ্বিধা বোধ করুন

— টেনসিবাই

@ Johannes'fish'Ziemke BTW devops.se উপর স্বাগতম :)

— Tensibai

1

কয়েকটি কারণ রয়েছে যা ব্যবধানের কারণ হতে পারে। সম্ভবত upটাইমসিরিজগুলি 0 কী ক্ষেত্রে রফতানিকারীর কাছে পৌঁছানো সম্ভব নয় আপনি এই বিষয়ে সতর্ক করতে পারেন ( https://prometheus.io/docs/alerting/rules/#templating থেকে নেওয়া ):

# Alert for any instance that is unreachable for >5 minutes.
ALERT InstanceDown
  IF up == 0
  FOR 5m
  LABELS { severity = "page" }
  ANNOTATIONS {
    summary = "Instance {{ $labels.instance }} down",
    description = "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes.",
  }

স্থিতির পাতায় আপনাকে এটিও দেখতে হবে যে এটির বার্তা সহ এটি বন্ধ রয়েছে। দুর্ভাগ্যক্রমে অতীত ত্রুটি দেখার কোনও উপায় নেই তবে এটি ট্র্যাক করার জন্য একটি সমস্যা রয়েছে: https://github.com/prometheus/prometheus/issues/2820

আপনার প্রমিথিউস সার্ভারটি স্ক্র্যাপিং বন্ধ করার ফলে অতিরিক্ত লোড হতে পারে যা ফাঁকগুলি ব্যাখ্যা করবে। Storage needs throttling. Scrapes and rule evaluations will be skipped.সেক্ষেত্রে আপনার prometheus_target_skipped_scrapes_totalলগতে ত্রুটিগুলি দেখা উচিত এবং মেট্রিকগুলিতে বৃদ্ধি পাওয়া উচিত । আপনারও এটি সম্পর্কে সতর্ক হওয়া উচিত, যেমন:

ALERT PrometheusSkipsScrapes
  IF rate(prometheus_target_skipped_scrapes_total[2m]) > 0
  FOR 5m

— জোহানেস 'ফিশ' জিমকে
সূত্র

1

আপনি যদি দেখেন যে একই সমস্যাটি হয় তবে আমি নিশ্চিত নই। তবে আমরা জাভা অ্যাপ্লিকেশনগুলির জন্য এলোমেলো ফাঁকগুলি দেখেছি যা জিসি সেটিংস নির্দিষ্টভাবে সেট করে না। মানে আমরা যখন শূন্যস্থান দেখতে পাচ্ছিলাম তখন ডেটা সংগ্রহ বন্ধ হয়ে যায় কারণ জেভিএম সম্পূর্ণ জিসি করার সময় উদাহরণটির ক্রিয়াকলাপ বন্ধ হয়ে যায়। আপনি যদি জাভা ব্যবহার করেন তবে এটি ঘটতে পারে। আমাদের সংশোধন হ'ল তথ্য সংগ্রহের এই সময়ের ব্যবধানগুলি রোধ করতে জিসি ক্রিয়াকলাপের দৈর্ঘ্যের নির্দিষ্ট সীমা সহ স্পষ্টভাবে G1 আবর্জনা সংগ্রহকারী (জাভা 8+) ব্যবহার করা ছিল।

— CWA
সূত্র