[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6GXFRE2XT81Q764SGKS80GT":3,"skill-same:01M6GXFRE2XT81Q764SGKS80GT":83},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":31,"publishedAt":51,"linkOnly":52,"markdownContent":53,"markdownBody":54,"frontMatter":55,"refName":60,"commitSha":61,"skillDirectory":62,"forksCount":63,"repositoryHtmlUrl":64,"repositoryHomepageUrl":64,"ownerHtmlUrl":65,"ownerBlogUrl":66,"ownerDescription":67,"updatedAt":68,"install":69,"resources":82},"01M6GXFRE2XT81Q764SGKS80GT","Monitoring & Alerting Review",null,"Deep review of monitoring setup — SLO definition, alert quality, dashboard design, incident response readiness, and common alert anti-patterns.","malayvuong\u002Fagent-orchestra","malayvuong","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F13240975?v=4","01M6GXCDVPB2VPZMDZK1KF98M0","Nguyen Minh Vuong","01M6GXCE176VDX3XV4Z4KNR33J",1,"MIT","https:\u002F\u002Fgithub.com\u002Fmalayvuong\u002Fagent-orchestra\u002Fblob\u002Fmain\u002F.agent-orchestra\u002Fskills\u002Fmonitoring-review\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000013","分析与可视化","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[32,5,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50],"review","monitoring","alerting","prometheus","dashboard","grafana","incident response","risk","common","slo","sli","alert","dashboard design","pagerduty","incident","deep","logic","readiness","design","2026-11-10 10:12:30",false,"---\nname: Monitoring & Alerting Review\ndescription: Deep review of monitoring setup — SLO definition, alert quality, dashboard design, incident response readiness, and common alert anti-patterns.\nversion: 2026.3.1\nlicense: MIT\ntriggers:\n  lenses:\n    - logic\n    - risk\n  keywords:\n    - monitoring\n    - alerting\n    - slo\n    - sli\n    - dashboard\n    - prometheus\n    - grafana\n    - pagerduty\n---\n\nWhen reviewing monitoring and alerting configuration, apply the following checks.\n\n## SLO and SLI Definition\n\nVerify the service has defined SLOs (Service Level Objectives) with measurable SLIs (Service Level Indicators). Flag services without explicit availability, latency, or error rate targets. Check that SLOs are expressed as percentages over a rolling window (e.g., \"99.9% of requests complete within 500ms over 30 days\"), not vague statements.\n\nVerify SLIs are measured from the user's perspective (at the load balancer or API gateway), not internal service metrics. Flag SLIs that measure component health (CPU usage, memory) instead of user-visible behavior (request success rate, response time).\n\n## Alert Quality\n\nFlag alerts that fire on raw thresholds without duration windows — a momentary spike should not page someone at 3am. Verify alerts use sustained conditions: \"error rate > 1% for 5 minutes\" not \"error rate > 1% at any instant.\"\n\nFlag alerts without clear ownership — every alert must route to a specific team or person. Flag alerts without a runbook link — an oncall engineer receiving an alert at 3am needs immediate guidance, not a ticket to investigate.\n\nCheck for alert fatigue: flag services with more than 10 active alerting rules — most should be informational, with only 3-5 paging alerts. Flag alerts that fire more than once per week without resolution — these are either misconfigured or accepted background noise that should be silenced.\n\n## Symptom vs Cause Alerting\n\nVerify alerts fire on symptoms (user-visible impact: error rate, latency, availability) not causes (CPU usage, memory, disk). Flag CPU alerts as paging alerts — high CPU without user impact is not urgent. Flag disk space alerts set at 90% with no action until 95% — alert at the threshold where action is needed.\n\nFlag alerts on individual instance metrics for services that are horizontally scaled — a single unhealthy instance in a pool of 20 is not a user-facing incident.\n\n## Dashboard Design\n\nVerify dashboards have a clear hierarchy: overview dashboard → service dashboard → debug dashboard. Flag dashboards with more than 20 panels — these are unusable during an incident. Check that the overview dashboard answers \"is the service healthy?\" in under 5 seconds of looking at it.\n\nVerify dashboards show the four golden signals: latency, traffic, errors, saturation. Flag dashboards that show only infrastructure metrics (CPU, memory, disk) without request-level metrics.\n\nCheck that dashboards use consistent time ranges and refresh intervals. Flag dashboards with panels that query different time windows — this creates misleading visual correlations.\n\n## Metric Design\n\nFlag metrics with unbounded label cardinality (user ID, request ID, IP address as labels) — these explode storage and query cost. Verify histogram buckets match the expected latency distribution — default buckets are often wrong for specific services.\n\nFlag counters that are used as gauges (reset on restart without handling) and gauges that should be counters (monotonically increasing values). Verify rate calculations use `rate()` or `irate()` over counters, not raw counter values.\n\n## Incident Response Readiness\n\nVerify escalation policies exist — if the primary oncall does not acknowledge within N minutes, the alert escalates. Flag services without a documented incident response procedure. Check that post-incident review (postmortem) is a defined process, not ad-hoc.\n\nVerify monitoring covers dependencies: if the service calls a database, cache, or external API, there should be metrics on those dependency calls (latency, error rate). Flag services that can detect their own failures but not their dependencies' failures.\n\n## Common Anti-Patterns\n\nFlag monitoring that was added after an incident but never reviewed — accumulated reactive monitoring becomes noise. Flag percentage-based alerts on low-traffic services (1 error out of 10 requests = 10% error rate). Verify low-traffic services use absolute counts, not percentages.\n\nFlag missing monitors for critical business flows (user registration, payment, checkout) — even if individual API endpoints are monitored, the end-to-end flow may not be.\n\nFor each finding, report: the alert rule or dashboard, the specific monitoring issue, and the recommended fix.\n","When reviewing monitoring and alerting configuration, apply the following checks.\n\n## SLO and SLI Definition\n\nVerify the service has defined SLOs (Service Level Objectives) with measurable SLIs (Service Level Indicators). Flag services without explicit availability, latency, or error rate targets. Check that SLOs are expressed as percentages over a rolling window (e.g., \"99.9% of requests complete within 500ms over 30 days\"), not vague statements.\n\nVerify SLIs are measured from the user's perspective (at the load balancer or API gateway), not internal service metrics. Flag SLIs that measure component health (CPU usage, memory) instead of user-visible behavior (request success rate, response time).\n\n## Alert Quality\n\nFlag alerts that fire on raw thresholds without duration windows — a momentary spike should not page someone at 3am. Verify alerts use sustained conditions: \"error rate > 1% for 5 minutes\" not \"error rate > 1% at any instant.\"\n\nFlag alerts without clear ownership — every alert must route to a specific team or person. Flag alerts without a runbook link — an oncall engineer receiving an alert at 3am needs immediate guidance, not a ticket to investigate.\n\nCheck for alert fatigue: flag services with more than 10 active alerting rules — most should be informational, with only 3-5 paging alerts. Flag alerts that fire more than once per week without resolution — these are either misconfigured or accepted background noise that should be silenced.\n\n## Symptom vs Cause Alerting\n\nVerify alerts fire on symptoms (user-visible impact: error rate, latency, availability) not causes (CPU usage, memory, disk). Flag CPU alerts as paging alerts — high CPU without user impact is not urgent. Flag disk space alerts set at 90% with no action until 95% — alert at the threshold where action is needed.\n\nFlag alerts on individual instance metrics for services that are horizontally scaled — a single unhealthy instance in a pool of 20 is not a user-facing incident.\n\n## Dashboard Design\n\nVerify dashboards have a clear hierarchy: overview dashboard → service dashboard → debug dashboard. Flag dashboards with more than 20 panels — these are unusable during an incident. Check that the overview dashboard answers \"is the service healthy?\" in under 5 seconds of looking at it.\n\nVerify dashboards show the four golden signals: latency, traffic, errors, saturation. Flag dashboards that show only infrastructure metrics (CPU, memory, disk) without request-level metrics.\n\nCheck that dashboards use consistent time ranges and refresh intervals. Flag dashboards with panels that query different time windows — this creates misleading visual correlations.\n\n## Metric Design\n\nFlag metrics with unbounded label cardinality (user ID, request ID, IP address as labels) — these explode storage and query cost. Verify histogram buckets match the expected latency distribution — default buckets are often wrong for specific services.\n\nFlag counters that are used as gauges (reset on restart without handling) and gauges that should be counters (monotonically increasing values). Verify rate calculations use `rate()` or `irate()` over counters, not raw counter values.\n\n## Incident Response Readiness\n\nVerify escalation policies exist — if the primary oncall does not acknowledge within N minutes, the alert escalates. Flag services without a documented incident response procedure. Check that post-incident review (postmortem) is a defined process, not ad-hoc.\n\nVerify monitoring covers dependencies: if the service calls a database, cache, or external API, there should be metrics on those dependency calls (latency, error rate). Flag services that can detect their own failures but not their dependencies' failures.\n\n## Common Anti-Patterns\n\nFlag monitoring that was added after an incident but never reviewed — accumulated reactive monitoring becomes noise. Flag percentage-based alerts on low-traffic services (1 error out of 10 requests = 10% error rate). Verify low-traffic services use absolute counts, not percentages.\n\nFlag missing monitors for critical business flows (user registration, payment, checkout) — even if individual API endpoints are monitored, the end-to-end flow may not be.\n\nFor each finding, report: the alert rule or dashboard, the specific monitoring issue, and the recommended fix.\n",{"name":5,"license":15,"version":56,"triggers":57,"description":7},"2026.3.1",{"lenses":58,"keywords":59},[48,39],[33,34,41,42,36,35,37,45],"main","eac6069a8690d89fd23f08d2d14e4874ed376a77",".agent-orchestra\u002Fskills\u002Fmonitoring-review",0,"https:\u002F\u002Fgithub.com\u002Fmalayvuong\u002Fagent-orchestra","https:\u002F\u002Fgithub.com\u002Fmalayvuong","www.malayvuong.com","Just a newbie at everything","2026-10-09 12:52:45",{"source":8,"skillName":5,"commands":70,"prompt":80,"zipAvailable":81},[71,74,77],{"tool":72,"command":73},"npx","npx skills add malayvuong\u002Fagent-orchestra --skill \"Monitoring & Alerting Review\"",{"tool":75,"command":76},"bunx","bunx skills add malayvuong\u002Fagent-orchestra --skill \"Monitoring & Alerting Review\"",{"tool":78,"command":79},"pnpm","pnpm dlx skills add malayvuong\u002Fagent-orchestra --skill \"Monitoring & Alerting Review\"","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmalayvuong\u002Fagent-orchestra\u002Fblob\u002Fmain\u002F.agent-orchestra\u002Fskills\u002Fmonitoring-review\u002FSKILL.md",true,[],[84,117,137,154,178,198],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":100,"publishedAt":51},"01M6GXHYPRJ43SHFPFJTF87GS8","Vue.js Review","Deep review of Vue.js applications — Composition API patterns, reactivity traps, component design, Pinia state management, and performance pitfalls.","https:\u002F\u002Fgithub.com\u002Fmalayvuong\u002Fagent-orchestra\u002Fblob\u002Fmain\u002F.agent-orchestra\u002Fskills\u002Fvue-review\u002FSKILL.md",[90,93,96,97],{"categoryNo":91,"categoryName":92,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":94,"categoryName":95,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":98,"categoryName":99,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000030","开发工程师",[32,101,102,103,50,104,105,106,107,108,109,110,111,112,113,114,47,48,115,116],"vue","js","Vue js Review","performance","component","state management","state","deep review","api patterns","applications","api","Composition","pinia","management","pitfalls","pinia state",{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":123,"publishedAt":51},"01M6GXHSPDDH1PQEN61ENMCEF5","Unity Review","Deep review of Unity C# code — object pooling, Update allocation, physics patterns, UI performance, serialization, and mobile optimization.","https:\u002F\u002Fgithub.com\u002Fmalayvuong\u002Fagent-orchestra\u002Fblob\u002Fmain\u002F.agent-orchestra\u002Fskills\u002Funity-review\u002FSKILL.md",[],[32,124,119,104,125,126,108,127,128,129,130,131,132,47,48,133,134,135,136],"unity","update","code","ui","serialization","Optimization","mobile","patterns","physics","C#","mobile optimization","object","allocation",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":143,"publishedAt":51},"01M6GXHNKTH12CGSRWDGF2H1Q9","TypeScript Review","Deep review of TypeScript code — type safety, generics patterns, strict mode compliance, type narrowing, module boundaries, and common escape hatches.","https:\u002F\u002Fgithub.com\u002Fmalayvuong\u002Fagent-orchestra\u002Fblob\u002Fmain\u002F.agent-orchestra\u002Fskills\u002Ftypescript-review\u002FSKILL.md",[],[32,144,145,126,108,146,147,148,40,131,47,48,149,150,151,152,153],"typescript","typescript review","compliance","Type Safety","Safety","module","type","interface","consistency","mode",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":166,"publishedAt":51},"01M6GXHH3DMZD272RVH4800C67","Test Conventions","Testing patterns and conventions for code review. Covers naming, AAA structure, boundary testing, mock vs real dependencies, and coverage expectations.","https:\u002F\u002Fgithub.com\u002Fmalayvuong\u002Fagent-orchestra\u002Fblob\u002Fmain\u002F.agent-orchestra\u002Fskills\u002Ftest-conventions\u002FSKILL.md",[160,163],{"categoryNo":161,"categoryName":162,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":164,"categoryName":165,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[167,168,156,169,170,32,126,171,172,173,131,174,175,176,177],"test","conventions","code review","testing","testing patterns","boundary","coverage","dependencies","structure","mock","naming",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":188,"publishedAt":51},"01M6GXHCAQSJDVNVRFFD1HJWTN","Terraform Review","Deep review of Terraform\u002FOpenTofu configuration — state management, module design, security hardening, drift prevention, and production safety patterns.","https:\u002F\u002Fgithub.com\u002Fmalayvuong\u002Fagent-orchestra\u002Fblob\u002Fmain\u002F.agent-orchestra\u002Fskills\u002Fterraform-review\u002FSKILL.md",[184,187],{"categoryNo":185,"categoryName":186,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[32,189,180,50,190,106,107,108,191,192,193,194,148,195,114,196,197,47,48,149],"terraform","security","cloud","aws","hardening","Production","opentofu","iac","drift",{"skillNo":199,"name":200,"nameZh":6,"description":201,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":202,"categories":203,"keywords":205,"publishedAt":51},"01M6GXH83F11CK4BQEAJPN6HDE","Swift Review","Deep review of Swift code — memory management, concurrency patterns, optionals, protocol design, SwiftUI lifecycle, and iOS platform patterns.","https:\u002F\u002Fgithub.com\u002Fmalayvuong\u002Fagent-orchestra\u002Fblob\u002Fmain\u002F.agent-orchestra\u002Fskills\u002Fswift-review\u002FSKILL.md",[204],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[206,32,200,50,207,104,126,208,108,209,210,211,212,213,114,47,48,214,215,216],"swift","memory","protocol","ios","concurrency","lifecycle","swiftui","uikit","xcode","apple","platform"]