-
Notifications
You must be signed in to change notification settings - Fork 2
WIP: state based alerting #392
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,16 @@ | ||
apiVersion: canaries.flanksource.com/v1 | ||
kind: Canary | ||
metadata: | ||
name: kubernetes-checks | ||
annotations: | ||
trace: "true" | ||
spec: | ||
schedule: "@every 5m" | ||
kubernetes: | ||
- name: pods | ||
kind: Pod | ||
namespaceSelector: | ||
name: default | ||
resource: | ||
name: test-pod | ||
healthy: true # use the is-healthy library to check the health of pods |
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,8 @@ | ||
apiVersion: v1 | ||
kind: Pod | ||
metadata: | ||
name: test-pod | ||
spec: | ||
containers: | ||
- image: nginx:invalid | ||
name: nginx |
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
@@ -0,0 +1,55 @@ | ||||||
Write a 1250-1500 introductor blog post for a DevOps / Platform Engineering focused product or feature. | ||||||
Check failure on line 1 in prompts/blog.md
|
||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Replace 'introductor' with 'introductory' to improve clarity.
Suggested change
Copilot uses AI. Check for mistakes. Positive FeedbackNegative Feedback |
||||||
|
||||||
The tone should be developer-friendly, technical and informative without sounding salesy or promotional. | ||||||
Check failure on line 3 in prompts/blog.md
|
||||||
|
||||||
The writing should have no fluff, use short punchy sentences, avoid buzzwords and speak like a senior engineer would. | ||||||
|
||||||
The purpose of this copy is to generate interest in a new approach to a feature, educate DevOps engineers, increase awareness and reduce friction to trial | ||||||
|
||||||
Speak directly to platform engineers, SREs and DevOps leads and address their pain points of change and tool fatigue. | ||||||
Check failure on line 9 in prompts/blog.md
|
||||||
|
||||||
Avoid generic language. Favor clarity over cleverness. Highlight real-world outcomes and developer-first thinking. | ||||||
|
||||||
Including working code examples / snippets and links were appropriate. | ||||||
|
||||||
Format the output in raw markdown suitable for copy and pasting into vscode. | ||||||
Check failure on line 15 in prompts/blog.md
|
||||||
|
||||||
Write a blog post on Flanksource MIssion Control approach to AIops, primarily building a real-time and update to mirror state of cloud resources that can be queried rapidly, plus an advanced graph that builds relationships between resources e.g. Cloudformation -> Auto Scaling Group > EC2 instance and then layers on soft relationsyhips like ebs volumes, subnets, IAM poilcies - For Kubernetes it understands Flux and Gitops being able to build a graph of a Flux Kustomization object creating a HelmRelease CRD, which then creates a deployment -> replicset -> pod and then layeying relationships like services, nodes, PVC, ingress, etc.. | ||||||
Check failure on line 17 in prompts/blog.md
|
||||||
|
||||||
State based alerting (i.e. whene resource self-report failure) and traditioanl alerts from APM tools trigger playbooks that can then proactively collect infomation in a distrubuted fashion from agents deployed closest to the data, the graph, changes to the graph resources, events and pro-acrtive playboks are then fed into the model which tan the recommend futher playbooks to execute. | ||||||
Check failure on line 19 in prompts/blog.md
|
||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There are multiple typos in this line: 'whene' should be 'when', 'traditioanl' should be 'traditional', 'infomation' should be 'information', 'distrubuted' should be 'distributed', 'pro-acrtive' should be 'proactive', 'playboks' should be 'playbooks', 'tan' should be 'to', and 'futher' should be 'further'.
Suggested change
Copilot uses AI. Check for mistakes. Positive FeedbackNegative Feedback |
||||||
|
||||||
This is advantage as acess to systems is pushed down to agents who can use secrets like pod identity and service accounts to collect duta, new agent actions are use to create with YAML based playbooks. | ||||||
Check failure on line 21 in prompts/blog.md
|
||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Correct 'acess' to 'access' and 'duta' to 'data' to improve clarity.
Suggested change
Copilot uses AI. Check for mistakes. Positive FeedbackNegative Feedback |
||||||
|
||||||
Write a blog post on the benefits of GitOps and the challenges of adoption - especially with mixed maturity teams (some prefer working in git and others like clickops) - Highlight the mission control approach to gitops (tracking resources and building a graph on how they map to git repository and sources), which enables "editing" kubernetes objects with the changes being submitted back to git. The benefits include a | ||||||
Check failure on line 23 in prompts/blog.md
|
||||||
|
||||||
contrasting metrics vs state driven alerting, store with concepts such as RED and USE and how they are more apropriate for monitoring transactions and staady state workloads and fall short for more platform engineering tasks such as monitoring the rollout of a new application or checking if a cluster is healthy after an upgrade. and then use examples of Prometheus and the canary-checker kubernetes check (https://flanksource.com/docs/guide/canary-checker/reference/kubernetes) which used the underlying https://github.com/flanksource/is-healthy library | ||||||
Check notice on line 25 in prompts/blog.md
|
||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Correct 'apropriate' to 'appropriate' and 'staady' to 'steady'.
Suggested change
Copilot uses AI. Check for mistakes. Positive FeedbackNegative Feedback |
||||||
|
||||||
Highlight the drawbacks of the canary-checker approach that is poll-based and does not scale very well and demononstrate how https://github.com/flanksource/config-db takes this one step further by using a state driven approach that watches for changes to cloud resources, and then fires events when the state becomes unhealthy. | ||||||
Check warning on line 27 in prompts/blog.md
|
||||||
|
||||||
|
||||||
is more scalable and can be used to monitor the health of a cluster or application in real-time. | ||||||
Check notice on line 30 in prompts/blog.md
|
||||||
|
||||||
Optionally, include {optional elements} (e.g. a strong CTA, technical example, code snippet, customer proof, comparison table). | ||||||
Check notice on line 32 in prompts/blog.md
|
||||||
|
||||||
|
||||||
Act as a technical blog writer targeting devops and platform engineers working with Kubernetes, GitOps, Helm and Flux, when editing and rewriting content follow these instructions strictly: | ||||||
Check failure on line 35 in prompts/blog.md
|
||||||
|
||||||
1. Use the following outline for the blog: | ||||||
* Introduction - introduce the topic of the blog with a pain point or teaser | ||||||
* Background - Describe the context and initial challenges. | ||||||
* Step by step guide | ||||||
* Common Pitfalls - Highlight common mistakes and how to avoid them and add use-cases that are not a good fiit | ||||||
Check failure on line 41 in prompts/blog.md
|
||||||
* Conclustion - Offer final thoughts and potential future implications. | ||||||
Check failure on line 42 in prompts/blog.md
|
||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Correct 'Conclustion' to 'Conclusion'.
Suggested change
Copilot uses AI. Check for mistakes. Positive FeedbackNegative Feedback |
||||||
2. Write at a Grade 10 level | ||||||
3. Use clear, concise simple language, even when explaining complex topics. | ||||||
Check failure on line 44 in prompts/blog.md
|
||||||
4. Bias toward short sentences. | ||||||
5. Mix and match lists and paragraphs | ||||||
6. Do not use any salesy or marketing terms, Do not use adverbs | ||||||
Check failure on line 47 in prompts/blog.md
|
||||||
7. Use MDX formatting | ||||||
Check notice on line 48 in prompts/blog.md
|
||||||
8. Precede every command with an explanation of what the command does. After the command, provide additional details about the command, such as what the arguments do and why your reader is using them. | ||||||
Check notice on line 49 in prompts/blog.md
|
||||||
9. Explicitly tell the user to create or open each file you’ll have them use. | ||||||
10. Like commands, always introduce a file or script by describing its general purpose, then explain any changes that the reader will be making in the file. Without these explanations, readers won’t be able to customize, update, or troubleshoot issues in the long run. | ||||||
Check warning on line 51 in prompts/blog.md
|
||||||
11. If you’re asking the reader to write code, follow the same approach for commands: introduce the code block with a high-level explanation of what it does. Then show the code, and then call out any important details. | ||||||
12. Do not use the term "this document", when referring to the system or product being documented always use "Mission Control" | ||||||
Check notice on line 53 in prompts/blog.md
|
||||||
13. Ensure all examples and use cases are relevant | ||||||
|
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
@@ -0,0 +1,56 @@ | ||||||
# Writing Style Guidelines | ||||||
|
||||||
Follow these strict rules: | ||||||
|
||||||
1. Avoid adverbs and complex language | ||||||
|
||||||
## Formating | ||||||
Check failure on line 7 in prompts/style.md
|
||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Correct the heading from 'Formating' to 'Formatting'.
Suggested change
Copilot uses AI. Check for mistakes. Positive FeedbackNegative Feedback |
||||||
- Format all output using MDX (markdowon) | ||||||
Check notice on line 8 in prompts/style.md
|
||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Correct the typo 'markdowon' to 'markdown'.
Suggested change
Copilot uses AI. Check for mistakes. Positive FeedbackNegative Feedback |
||||||
- Format code and examples using this example: | ||||||
|
||||||
```yaml title=some-title.yaml | ||||||
``` | ||||||
- Do not remove any "```" or "//highlight-next-line" text | ||||||
- Follow standard markdown rules provided by markdownlint | ||||||
Check failure on line 14 in prompts/style.md
|
||||||
|
||||||
|
||||||
## Verb Tense | ||||||
- Use present tense verbs instead of future tense. | ||||||
- Say "this happens" rather than "this will happen." | ||||||
Check warning on line 19 in prompts/style.md
|
||||||
- Avoid words like "will," "shall," "won't," "shan't," and contractions with "'ll." | ||||||
Check warning on line 20 in prompts/style.md
|
||||||
|
||||||
## Voice | ||||||
- Do not use first person (I, me, my, mine, we, our). | ||||||
Check failure on line 23 in prompts/style.md
|
||||||
- Avoid phrases like "I'd," "I'll," "I'm," and "I've." | ||||||
Check failure on line 24 in prompts/style.md
|
||||||
- Use passive voice sparingly. Active voice is generally clearer. | ||||||
Check warning on line 25 in prompts/style.md
|
||||||
|
||||||
## Inclusive Language | ||||||
- Use considerate language that respects all readers. | ||||||
- Use "they" as a singular pronoun instead of "he/she" or "s/he." | ||||||
Check failure on line 29 in prompts/style.md
|
||||||
- Avoid terms that might be insensitive: | ||||||
- Replace "sane" with "correct," "adequate," "sensible," etc. | ||||||
Check warning on line 31 in prompts/style.md
|
||||||
- Replace "crazy/insane" with "extremely," "very," "illogical," etc. | ||||||
Check warning on line 32 in prompts/style.md
|
||||||
- Replace "dummy" with "placeholder" or "test" | ||||||
Check warning on line 33 in prompts/style.md
|
||||||
- Replace "hang" with "freeze" or "become unresponsive" | ||||||
Check warning on line 34 in prompts/style.md
|
||||||
- Avoid phrases like "fall on deaf ears" or "blind spot" | ||||||
Check warning on line 35 in prompts/style.md
|
||||||
|
||||||
## Tone | ||||||
- Don't assume success with statements like "congratulations," "that's it," or "you did it." | ||||||
Check failure on line 38 in prompts/style.md
|
||||||
- Avoid condescending terms like "obvious," "obviously," "simple," "simply," "easy," "easily," "of course," "clearly," or "everyone knows." | ||||||
Check failure on line 39 in prompts/style.md
|
||||||
- Don't add "-ly" to ordinal numbers (avoid "firstly," "secondly," etc.) | ||||||
Check failure on line 40 in prompts/style.md
|
||||||
|
||||||
## Clarity and Brevity | ||||||
- Use simple words instead of complex ones. | ||||||
Check failure on line 43 in prompts/style.md
|
||||||
- Avoid foreign phrases like "i.e.," "viz.," or "ergo." | ||||||
Check failure on line 44 in prompts/style.md
|
||||||
- Eliminate wordiness and redundant phrases: | ||||||
Check notice on line 45 in prompts/style.md
|
||||||
- "in order to" → "to" | ||||||
Check warning on line 46 in prompts/style.md
|
||||||
- "due to the fact that" → "because" | ||||||
Check warning on line 47 in prompts/style.md
|
||||||
- "at this point in time" → "now" | ||||||
Check warning on line 48 in prompts/style.md
|
||||||
- "in the event that" → "if" | ||||||
Check warning on line 49 in prompts/style.md
|
||||||
- Remove phrases that don't add clarity: | ||||||
- "note that" | ||||||
Check failure on line 51 in prompts/style.md
|
||||||
- "it is important to note" | ||||||
Check failure on line 52 in prompts/style.md
|
||||||
- "keep in mind" | ||||||
- "as you can see" | ||||||
Check failure on line 54 in prompts/style.md
|
||||||
|
||||||
Remember that clear, direct language helps readers understand your content more easily. | ||||||
Check failure on line 56 in prompts/style.md
|
Original file line number | Diff line number | Diff line change | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
@@ -19,25 +19,24 @@ exceptions: | |||||||||||||
- CRUD | ||||||||||||||
- CSS | ||||||||||||||
- CSV | ||||||||||||||
- RDS | ||||||||||||||
- SQS | ||||||||||||||
- Subnet | ||||||||||||||
- IAMRole | ||||||||||||||
- ECSTask | ||||||||||||||
- ECSCluster | ||||||||||||||
- EBSVolume | ||||||||||||||
- EBSVolume | ||||||||||||||
- DNSZone | ||||||||||||||
- DEBUG | ||||||||||||||
- DHCP | ||||||||||||||
- ECS | ||||||||||||||
- DNS | ||||||||||||||
- EKS | ||||||||||||||
- IAM | ||||||||||||||
- IRSA | ||||||||||||||
- VPC | ||||||||||||||
- DEBUG | ||||||||||||||
- DNSZone | ||||||||||||||
- DOM | ||||||||||||||
- DPI | ||||||||||||||
- EBS | ||||||||||||||
- EBSVolume | ||||||||||||||
- ECR | ||||||||||||||
- ECS | ||||||||||||||
- ECSCluster | ||||||||||||||
- ECSService | ||||||||||||||
- ECSTask | ||||||||||||||
- ECSTask | ||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The acronym 'ECSTask' appears more than once; please remove duplicate entries to keep the list concise.
Suggested change
Copilot uses AI. Check for mistakes. Positive FeedbackNegative Feedback |
||||||||||||||
- EFS | ||||||||||||||
- EKS | ||||||||||||||
- EKSCluster | ||||||||||||||
- EKSCluster | ||||||||||||||
- FAQ | ||||||||||||||
- GCC | ||||||||||||||
Comment on lines
+39
to
41
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The acronym 'EKSCluster' is duplicated; consider removing one instance to prevent redundancy.
Suggested change
Copilot uses AI. Check for mistakes. Positive FeedbackNegative Feedback |
||||||||||||||
- GDB | ||||||||||||||
|
@@ -48,7 +47,11 @@ exceptions: | |||||||||||||
- HTML | ||||||||||||||
- HTTP | ||||||||||||||
- HTTPS | ||||||||||||||
- IAM | ||||||||||||||
- IAMRole | ||||||||||||||
- IAMUser | ||||||||||||||
- IDE | ||||||||||||||
- IRSA | ||||||||||||||
- JAR | ||||||||||||||
- JPG | ||||||||||||||
- JSON | ||||||||||||||
|
@@ -65,14 +68,21 @@ exceptions: | |||||||||||||
- POST | ||||||||||||||
- RAM | ||||||||||||||
- RBAC | ||||||||||||||
- RDS | ||||||||||||||
- RDSInstance | ||||||||||||||
- REPL | ||||||||||||||
- RSA | ||||||||||||||
- SCM | ||||||||||||||
- SCSS | ||||||||||||||
- SDK | ||||||||||||||
- SNS | ||||||||||||||
- SNSTopic | ||||||||||||||
- SQL | ||||||||||||||
- SQS | ||||||||||||||
- SQSQueue | ||||||||||||||
- SSH | ||||||||||||||
- SSL | ||||||||||||||
- Subnet | ||||||||||||||
- SVG | ||||||||||||||
- TBD | ||||||||||||||
- TCP | ||||||||||||||
|
@@ -82,6 +92,7 @@ exceptions: | |||||||||||||
- USB | ||||||||||||||
- UTF | ||||||||||||||
- UUID | ||||||||||||||
- VPC | ||||||||||||||
- XML | ||||||||||||||
- XSS | ||||||||||||||
- YAML | ||||||||||||||
|
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -5,10 +5,4 @@ level: error | |||||
action: | ||||||
name: replace | ||||||
swap: | ||||||
"[Ii]ngress.NGINX": Ingress-NGINX | ||||||
".ngress.[Nn]ginx": Ingress-NGINX | ||||||
"[Nn]ginx [Ii]ngress [Cc]ontroller": NGINX Ingress Controller | ||||||
"NGINX ingress [Cc]ontroller": NGINX Ingress Controller | ||||||
"NGINX [Ii]ngress controller": NGINX Ingress Controller | ||||||
"(?<!Ingress-)(?:Nginx|NGINX)(?! Ingress)": nginx | ||||||
"(?<!Ingress-)(?:Nginx|NGINX)'s(?! Ingress)": nginx's | ||||||
"[Nn]ginx": "nginx" | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. [nitpick] Verify that the new mapping for '[Nn]ginx' is consistent with existing rules and desired capitalization outcomes.
Suggested change
Copilot uses AI. Check for mistakes. Positive FeedbackNegative Feedback |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The image tag 'nginx:invalid' appears to be a mistake that may cause runtime failures; please verify and update it with a valid tag.
Copilot uses AI. Check for mistakes.