cwielenb/CNCF-Dataset huggingface dataset:
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_service.Service.md

title: "Class: Service" linkTitle: "Service" slug: "libk8sservice.Service" .Service `any` `Service` new Service(`json`) | Name | Type | | : | : | | `json` | | makeKubeObject<KubeService\>('service').constructor `Static` apiEndpoint: `Object` | Name | Type | | : | : | | `scale?` | { `get`: (`namespace`: `string`, `name`: `string`, `clusterName?`: `string`) => `Promise`<`any`\> ; `put`: (`body`: { `metadata`: ; `spec`: { `replicas`: `number` } }, `clusterName?`: `string`) => `Promise`<`any`\> } | | `scale.get` | (`namespace`: `string`, `name`: `string`, `clusterName?`: `string`) => `Promise`<`any`\> | | `scale.put` | (`body`: { `metadata`: ; `spec`: { `replicas`: `number` } }, `clusterName?`: `string`) => `Promise`<`any`\> | _ `Static` className: `string` makeKubeObject<KubeService\>('service').className `get` spec(): `Object` `Object` | Name | Type | | : | : | | `clusterIP` | `string` | | `externalIPs` | `string`[] | | `ports` | { `name`: `string` ; `nodePort`: `number` ; `port`: `number` ; `protocol`: `string` ; `targetPort`: `string` \| `number` }[] | | `selector` | { `[key: string]`: `string`; } | | `type` | `string` | _ `get` status(): `any` `any` getExternalAddresses(): `string` `string` _ getPorts(): `number`[] `number`[] _ getSelector(): `string`[] `string`[] _ `Static` apiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeService\>('service').apiList _ `Static` `Optional` getAuthorization(`arg`, `resourceAttrs?`): `any` | Name | Type | | : | : | | `arg` | `string` | | `resourceAttrs?` | | `any` makeKubeObject<KubeService\>('service').getAuthorization _ `Static` getErrorMessage(`err?`): ``null`` \| `string` | Name | Type | | : | : | | `err?` | ``null`` \| | ``null`` \| `string` makeKubeObject<KubeService\>('service').getErrorMessage _ `Static` useApiGet(`onGet`, `name`, `namespace?`, `onError?`): `void` | Name | Type | | : | : | | `onGet` | (...`args`: `any`) => `void` | | `name` | `string` | | `namespace?` | `string` | | `onError?` | (`err`: ) => `void` | `void` makeKubeObject<KubeService\>('service').useApiGet _ `Static` useApiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeService\>('service').useApiList _ `Static` useGet(`name`, `namespace?`): , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] | Name | Type | | : | : | | `name` | `string` | | `namespace?` | `string` | , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] makeKubeObject<KubeService\>('service').useGet _ `Static` useList(`opts?`): , (`items`: `any`) => `void`] | Name | Type | | : | : | | `opts?` | | , (`items`: `any`) => `void`] makeKubeObject<KubeService\>('service').useList
Project: Grafana Loki (Observability and Analysis / Observability)
File: concepts.md

title: Helm chart components menuTitle: Helm chart components description: A short introduction to the components installed with the Loki Helm Chart. aliases: ../../../installation/helm/concepts/ weight: 100 keywords: dashboards gateway caching This section describes the components installed by the Helm Chart. By default Loki will be installed in the scalable mode. This consists of a read and write component. These can be scaled-out independently. This chart includes dashboards for monitoring Loki. These require the scrape configs defined in the `monitoring.serviceMonitor` and `monitoring.selfMonitoring` sections described below. The dashboards are deployed via a config map which can be mounted on a Grafana instance. The Dashboard require an installation of the Grafana Agent and the Prometheus operator. The agent is installed with this chart. This chart installs the and its alerts by default. This is another tool to verify the Loki deployment is in a healthy state. It can be disabled with `monitoring.lokiCanary.enabled=false`. By default and inspired by Grafana's , the chart installs the gateway component which is an NGINX that exposes Loki's API and automatically proxies requests to the correct Loki components (read or write, or single instance in the case of filesystem storage). The gateway must be enabled if an Ingress is required, since the Ingress exposes the gateway only. If the gateway is enabled, Grafana and log shipping agents, such as Promtail, should be configured to use the gateway. If NetworkPolicies are enabled, they are more restrictive if the gateway is enabled. By default, this chart configures in-memory caching. If that caching does not work for your deployment, you should setup memcache.
Project: Netdata (Observability and Analysis / Observability)
File: exporting_last_buffering.md

This alert is related to the Netdata Exporting engine, which calculates the number of seconds since the last successful buffering of exporting data. If you receive this alert, it means the exporting engine failed to buffer metrics for a while, and some metrics were lost during exporting. There might be issues with the exporting destination being down or unreachable. Check the exporting destination status and accessibility: If the exporting destination (e.g. a remote server or database) is down or unreachable, your priority should be to fix the connection issue or bring the destination back up. Investigate short-term network availability problems: Short-term network connectivity issues might cause temporary errors in the exporting process. You may want to check and monitor your network to confirm this is the case and fix any issues. Increase the `buffer on failures` value in `exporting.conf`: You can try to prevent short-term problems from causing alert issues by increasing the `buffer on failures` value in the `exporting.conf` file. To do this, edit the configuration file, find the parameter `buffer on failures`, and increase its value. ``` [exporting:global] buffer on failures = new_value ``` Replace `new_value` with the desired number that matches your system requirements. Restart the Netdata Agent: After modifying the `exporting.conf` file, don't forget to restart the Netdata Agent for changes to take effect. Use the following command to restart the agent: ``` sudo systemctl restart netdata ``` Monitor the `exportinglastbuffering` alert: After applying the changes, keep monitoring the `exportinglastbuffering` alert to check if the issue is resolved. If the alert continues, further investigate possible issues with the exporting engine or destination.
Project: Grafana (Observability and Analysis / Observability)
File: terminology.md

<!-- Keep terms in alphabetical order: --> This document defines technical terms used in Grafana. The acronyms (Transport Layer Security) and (Secure Socket Layer) are both used to describe the HTTPS security layer, and are in practice synonymous. However, TLS is considered the current name for the technology, and SSL is considered . As such, while both terms are in use (also in our codebase) and are indeed interchangeable, TLS is the preferred term. That said however, we have at Grafana Labs decided to use both acronyms in combination when referring to this type of technology, i.e. TLS/SSL. This is in order to not confuse those who may not be aware of them being synonymous, and SSL still being so prevalent in common discourse.
Project: gocrane (Observability and Analysis / Continuous Optimization)
File: introduction.md

title: "Introduction" description: "Main Introduction for Crane" weight: 10 Crane is a FinOps Platform for Cloud Resource Analytics and Economics in Kubernetes clusters. The goal is not only help user to manage cloud cost easier but also ensure the quality of applications. <img alt="fcs logo" height="200" src="/images/Crane-FinOps-Certified-Solution.png" title="FinOps Certified Solution" width="200"/> Crane is a project of the . How to start a Cost-Saving journey on Crane? Understanding: Cost insight for cloud assets and kubernetes resources(Deployments, StatefulSets). Analytics: Periodically analytics the states in cluster and provide optimization recommendations. Optimization: Rich set of functionalities to operate and reduce your cost. <iframe src="https://user-images.githubusercontent.com/35299017/186680122-d7756b47-06be-44cb-8553-1957eaa3ed45.mp4" scrolling="no" border="0" frameborder="no" framespacing="0" allowfullscreen="true" width="1000" height="600"></iframe> Live Demo for Crane Dashboard: http://dashboard.gocrane.io/ Cost Visualization and Optimization Evaluation Provides a collection of exporters which collect cloud resource pricing and billing data and ship to your monitoring system like Prometheus. Multi-dimensional cost insight, optimization evaluates are supported. Support Multi-cloud Pricing through `Cloud Provider` Recommendation Framework Provide a pluggable framework for analytics and give recommendation for cloud resources, support out-of-box recommenders: Workload Resources/Replicas/HPA, Idle Resources. . Prediction-driven Horizontal Autoscaling EffectiveHorizontalPodAutoscaler supports prediction-driven autoscaling. With this capability, user can forecast the incoming peak flow and scale up their application ahead, also user can know when the peak flow will end and scale down their application gracefully. . Load-Aware Scheduling Provide a simple but efficient scheduler that schedule pods based on actual node utilization dataand filters out those nodes with high load to balance the cluster. . Colocation with Enhanced QOS QOS-related capabilities ensure the running stability of Pods on Kubernetes. It has the ability of interference detection and active avoidance under the condition of multi-dimensional metrics, and supports reasonable operation and custom metrics access; it has the ability to oversell elastic resources enhanced by the prediction algorithm, reuse and limit the idle resources in the cluster; it has the enhanced bypass cpuset Management capabilities, improve resource utilization efficiency while binding cores. .
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-7-5-5.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 7.5.5 <!-- Auto generated by update changelog github action --> Explore: Load default data source in Explore when the provided source does not exist. , Instrumentation: Add success rate metrics for email notifications. , Alerting: Remove field limitation from Slack notifications. , Auth: Do not clear auth token cookie when token lookup fails. , Bug: Add git command to Dockerfile.ubuntu file. , Explore: Adjust time to the selected timezone. , GraphNG: Fix exemplars window position. , Loki: Pass Skip TLS Verify setting to alert queries. , Postgres: Fix time group macro when TimescaleDB is enabled and interval is less than a second. ,
Project: Grafana (Observability and Analysis / Observability)
File: configure-telegram.md

canonical: https://grafana.com/docs/grafana/latest/alerting/configure-notifications/manage-contact-points/integrations/configure-telegram/ description: Configure the Telegram integration to connect alerts generated by Grafana Alerting keywords: grafana alerting telegram integration labels: products: cloud enterprise oss menuTitle: Telegram title: Configure Telegram for Alerting weight: 300 Use the Grafana Alerting - Telegram integration to send notifications when your alerts are firing. To integrate Grafana with Telegram, you need to obtain a Telegram bot API token and a chat ID (i.e., the ID of the Telegram chat where you want to receive the alert notifications). Create a . You can associate this bot to your chats and perform different actions with it, such as receiving alerts from Grafana. To set up the bot, complete the following steps. Open the Telegram app on your device. Find the Telegram bot named BotFather. Type or press `/newbot`. Choose a name for the bot. It must end in bot or \_bot. E.g. "my_bot". Copy the API token. Add the bot to a group chat by following the steps below. Once the bot is added to the chat, you will be able to route your alert notifications to that group. In the Telegram app, open a group or start a new one. Search and add the bot to the group. Interact with the bot by sending a dummy message that starts with "`/`". E.g. `/hola @bot_name`. {{< figure src="/media/blog/telegram-grafana-alerting/telegram-screenshot.png" alt="A screenshot that shows a message to a Telegram bot." >}} To obtain the chat ID, send an to the bot. Copy the below URL and replace `{yourbotapi_token}` with your bot API token. ``` https://api.telegram.org/bot{yourbotapi_token}/getUpdates ``` Paste the URL in your browser. If the request is successful, it will return a response in JSON format. ``` ... "chat": { "id": -4065678900, "title": "Tony and Hello world bot", "type": "group", ... ``` Copy the value of the `id` that appears under `chat`. To create your Telegram integration in Grafana Alerting, complete the following steps. Navigate to Alerts & IRM -> Alerting -> Contact points. Click + Add contact point. Enter a contact point name. From the Integration list, select Telegram. In the BOT API Token field, copy in the bot API token. In the Chat ID field, copy in the chat ID. Click Test to check that your integration works. Click Save contact point. To add the contact point and integration you created to your default notification policy, complete the following steps. Navigate to Alerts & IRM -> Alerting -> Notification policies. In the Default policy, click the ellipsis icon () and then Edit. Change the default policy to the contact point you created. Click Update default policy. {{<admonition type="note">}} If you have more than one contact point, add a new child notification policy rather than edit the default one, so you can route specific alerts to Telegram. {{</admonition>}}
Project: Netdata (Observability and Analysis / Observability)
File: boinc_compute_errors.md

The `boinccomputeerrors` alert indicates that your system has experienced an increase in the average number of compute errors over the last 10 minutes when running BOINC tasks. It is important to identify the cause of these errors and take appropriate action to minimize the impact on your system. Check the BOINC client logs BOINC client logs can provide useful information about compute errors. The logs can usually be found in the `/var/lib/boinc-client/` directory. Look for any error messages or information that could indicate the cause of the issues. Verify the system requirements Ensure that your system meets the minimum requirements to run the BOINC tasks. This includes checking the CPU, RAM, disk space, and any other device-specific requirements. If your system does not meet the requirements, you may need to upgrade your hardware or reduce the number of tasks you are running simultaneously. Check for software and hardware compatibility Some BOINC tasks may have specific hardware or software requirements, such as GPU support or compatibility with certain operating systems. Check the BOINC project documentation for any specific requirements you may be missing. Update the BOINC client software Make sure your BOINC client software is up-to-date, as outdated versions can cause errors or unexpected behavior. You can check for updates and download the latest version from the . Restart the BOINC client If the issue persists, try restarting the BOINC client following the steps provided in the alert: Abort the running task Restart the BOINC client: ``` root@netdata # /etc/init.d/boinc-client restart ``` Seek assistance from the BOINC community If you continue to experience issues after following these troubleshooting steps, consider seeking assistance from the BOINC community through forums or mailing lists.
Project: Vector (Observability and Analysis / Observability)
File: 2022-03-15-vrl-vm-beta.md

date: "2022-03-15" title: "Beta release of a Virtual Machine to run VRL programs" description: "A faster way to run VRL" authors: ["StephenWakely"] pr_numbers: [9829] release: "0.21.0" hideonrelease_notes: false badges: type: enhancement As part of our performance improvements in Vector, we have developed a new Virtual Machine for running VRL programs. In our soak tests we are getting performance improvements of between 10-15% depending on the VRL program that is being run. You can give the VM a try by adding the `runtime` configuration option to your Remap transform: ```toml [transforms.remap] type = "remap" inputs = [ "..." ] runtime = "vm" source = ''' ... ''' ``` We are excited about the performance improvements that using a Virtual Machine will bring to Vector. If you have any feedback for us let us know on [Discord] or on [Twitter]. Currently VRL is run using a Tree Walking interpreter. A VRL program is compiled into a tree of program nodes. For example, given this simple VRL program: ```coffee if .flag == 42 { .field = 32 } else { .field = 15 } ``` VRL compiles that into the nodes similar to this: ```mermaid graph TD IF -->PREDICATE PREDICATE -->Equals[==] Equals -->Flag[.flag] Equals -->42 IF -->THEN THEN -->ASSIGN1[ASSIGN] ASSIGN1 -->Field1[.field] ASSIGN1 -->32 IF -->ELSE ELSE -->ASSIGN2[ASSIGN] ASSIGN2 -->Field2[.field] ASSIGN2 -->15 ``` As the VRL program is run each node is interpreted which decides what actions need to be taken and which node to execute next. The tree is walked in this manner until the program reaches a node that has no further nodes to execute. There are a number of advantages to running a program this way. It is fast to develop and the code is easy to maintain and debug since each node manages its own state. However, when it comes to performance there are a number of issues. Each node can take up a significant amount of memory - especially with large VRL programs. This causes particular issues when it comes to taking advantage of the CPU cache. So we have developed a Virtual Machine to execute VRL programs instead. A Virtual Machine is a simplified computer than is run in software rather than hardware. VRL programs are compiled to an array of instructions. Rather than general instructions that a CPU will execute we have defined a simple set of instructions specific to running VRL. Each instruction and the parameters it needs will take up just a few bytes. The whole program can be loaded into contiguous memory which allows us to take advantage of CPU caching. The above program is compiled into the following set of instructions: ```json [ "0000: GetPath", "0001: 0", "0002: Constant", "0003: 0", "0004: Equal", "0005: JumpIfFalse", "0006: 7", "0007: Pop", "0008: Constant", "0009: 1", "0010: SetPath", "0011: 1", "0012: Jump", "0013: 5", "0014: Pop", "0015: Constant", "0016: 2", "0017: SetPath", "0018: 1", "0019: Return", ] ``` The Virtual Machine steps through the list executing each instruction in turn.
Project: Checkmk (Observability and Analysis / Observability)
File: 16678.md

key | value | compatible | yes version | 2.4.0b1 date | 2024-04-10T09:08:54+00:00 level | 1 class | fix component | inv edition | cre Previously hosts marked for inventorization were afterwards not unmarked, meaning they would be processed again everytime the autoinventory was running. This has been fixed.
Project: Hubble (Observability and Analysis / Observability)
File: README.md

This package is a fork of the go-yaml library and is intended solely for consumption by kubernetes projects. In this fork, we plan to support only critical changes required for kubernetes, such as small bug fixes and regressions. Larger, general-purpose feature requests should be made in the upstream go-yaml library, and we will reject such changes in this fork unless we are pulling them from upstream. This fork is based on v2.4.0: https://github.com/go-yaml/yaml/releases/tag/v2.4.0 Introduction The yaml package enables Go programs to comfortably encode and decode YAML values. It was developed within as part of the project, and is based on a pure Go port of the well-known C library to parse and generate YAML data quickly and reliably. Compatibility The yaml package supports most of YAML 1.1 and 1.2, including support for anchors, tags, map merging, etc. Multi-document unmarshalling is not yet implemented, and base-60 floats from YAML 1.1 are purposefully not supported since they're a poor design and are gone in YAML 1.2. Installation and usage The import path for the package is gopkg.in/yaml.v2. To install it, run: go get gopkg.in/yaml.v2 API documentation -- If opened in a browser, the import path itself leads to the API documentation: API stability The package API for yaml v2 will remain stable as described in . License The yaml package is licensed under the Apache License 2.0. Please see the LICENSE file for details. Example ```Go package main import ( "fmt" "log" "gopkg.in/yaml.v2" ) var data = ` a: Easy! b: c: 2 d: [3, 4] ` // Note: struct fields must be public in order for unmarshal to // correctly populate the data. type T struct { A string B struct { RenamedC int `yaml:"c"` D []int `yaml:",flow"` } } func main() { t := T{} err := yaml.Unmarshal([]byte(data), &t) if err != nil { log.Fatalf("error: %v", err) } fmt.Printf(" t:\n%v\n\n", t) d, err := yaml.Marshal(&t) if err != nil { log.Fatalf("error: %v", err) } fmt.Printf(" t dump:\n%s\n\n", string(d)) m := make(map[interface{}]interface{}) err = yaml.Unmarshal([]byte(data), &m) if err != nil { log.Fatalf("error: %v", err) } fmt.Printf(" m:\n%v\n\n", m) d, err = yaml.Marshal(&m) if err != nil { log.Fatalf("error: %v", err) } fmt.Printf(" m dump:\n%s\n\n", string(d)) } ``` This example will generate the following output: ``` t: {Easy! {2 [3 4]}} t dump: a: Easy! b: c: 2 d: [3, 4] m: map[a:Easy! b:map[c:2 d:[3 4]]] m dump: a: Easy! b: c: 2 d: 3 4 ```