WIP: state based alerting

common/src/components/TerminalOutput.jsx

@@ -35,8 +35,19 @@ function ansi2HTML(str, command) {
 
 
 export default function Ansi({ command, children }) {
+  let txt = ""
+  try {
 
-  let txt = `❯ ${command}<br/>` + children.props.children.replaceAll("\n", "<br/>")
+
+    if (children?.props?.children) {
+      txt = `❯ ${command}<br/>` + children.props.children.replaceAll("\n", "<br/>")
+    } else {
+      txt = `❯ ${command}`
+    }
+  } catch (e) {
+    console.error(e)
+    txt = ""
+  }
 
   let html = new Convert().toHtml(txt, command)
   return (

mission-control/blog/state-based-alerting/canary.yaml

@@ -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

mission-control/blog/state-based-alerting/nginx.yaml

@@ -0,0 +1,8 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: test-pod
+spec:
+  containers:
+    - image: nginx:invalid
+      name: nginx

prompts/blog.md

@@ -0,0 +1,55 @@
+Write a 1250-1500 introductor blog post for a DevOps / Platform Engineering focused product or feature.
+
+The tone should be developer-friendly, technical and informative without sounding salesy or promotional.
+
+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.
+
+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.
+
+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..
+
+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. 
+
+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.
+
+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
+
+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
+
+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.
+
+
+ is more scalable and can be used to monitor the health of a cluster or application in real-time.
+
+Optionally, include {optional elements} (e.g. a strong CTA, technical example, code snippet, customer proof, comparison table).
+
+
+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:
+
+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
+   * Conclustion - Offer final thoughts and potential future implications.
+2. Write at a Grade 10 level
+3. Use clear, concise simple language, even when explaining complex topics.
+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
+7. Use MDX formatting
+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.
+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.
+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"
+13. Ensure all examples and use cases are relevant
+

prompts/style.md

@@ -0,0 +1,56 @@
+# Writing Style Guidelines
+
+Follow these strict rules:
+
+1.  Avoid adverbs and complex language
+
+## Formating
+- Format all output using MDX (markdowon)
+- 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
+
+
+## Verb Tense
+- Use present tense verbs instead of future tense.
+- Say "this happens" rather than "this will happen."
+- Avoid words like "will," "shall," "won't," "shan't," and contractions with "'ll."
+
+## Voice
+- Do not use first person (I, me, my, mine, we, our).
+- Avoid phrases like "I'd," "I'll," "I'm," and "I've."
+- Use passive voice sparingly. Active voice is generally clearer.
+
+## Inclusive Language
+- Use considerate language that respects all readers.
+- Use "they" as a singular pronoun instead of "he/she" or "s/he."
+- Avoid terms that might be insensitive:
+  - Replace "sane" with "correct," "adequate," "sensible," etc.
+  - Replace "crazy/insane" with "extremely," "very," "illogical," etc.
+  - Replace "dummy" with "placeholder" or "test"
+  - Replace "hang" with "freeze" or "become unresponsive"
+  - Avoid phrases like "fall on deaf ears" or "blind spot"
+
+## Tone
+- Don't assume success with statements like "congratulations," "that's it," or "you did it."
+- Avoid condescending terms like "obvious," "obviously," "simple," "simply," "easy," "easily," "of course," "clearly," or "everyone knows."
+- Don't add "-ly" to ordinal numbers (avoid "firstly," "secondly," etc.)
+
+## Clarity and Brevity
+- Use simple words instead of complex ones.
+- Avoid foreign phrases like "i.e.," "viz.," or "ergo."
+- Eliminate wordiness and redundant phrases:
+  - "in order to" → "to"
+  - "due to the fact that" → "because"
+  - "at this point in time" → "now"
+  - "in the event that" → "if"
+- Remove phrases that don't add clarity:
+  - "note that"
+  - "it is important to note"
+  - "keep in mind"
+  - "as you can see"
+
+Remember that clear, direct language helps readers understand your content more easily.

styles/Flanksource/Acronyms.yml

@@ -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
+  - EFS
+  - EKS
+  - EKSCluster
+  - EKSCluster
   - FAQ
   - GCC
   - 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

styles/Flanksource/CaseSensitiveSpellingSuggestions.yml

@@ -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"

styles/Flanksource/ComplexWords.yml

@@ -46,7 +46,6 @@ swap:
   collaborate: work together
   commence: begin
   compensate: pay
-  component: part
   comprise: form|include
   concerning: about
   confer: give|award