cwielenb/CNCF-Dataset huggingface dataset:
Project: InfluxData (Observability and Analysis / Observability)
File: bug_report.md

name: Bug report about: Create a report to help us improve <!-- Thank you for reporting a bug in InfluxDB IOx. Have you read the contributing section of the README? Please do if you haven't. https://github.com/influxdata/influxdb/blob/main/README.md Please ask usage questions in the Influx Slack (there is an #influxdb-iox channel). https://influxdata.com/slack Please don't open duplicate issues; use the search. If there is an existing issue please don't add "+1" or "me too" comments; only add comments with new information. Please check whether the bug can be reproduced with tip of main. The fastest way to fix a bug is to open a Pull Request. https://github.com/influxdata/influxdb/pulls --> Steps to reproduce: List the minimal actions needed to reproduce the behaviour. ... ... ... Expected behaviour: Describe what you expected to happen. Actual behaviour: Describe What actually happened. Environment info: Please provide the command you used to build the project, including any `RUSTFLAGS`. System info: Run `uname -srm` or similar and copy the output here (we want to know your OS, architecture etc). If you're running IOx in a containerised environment then details about that would be helpful. Other relevant environment details: disk info, hardware setup etc. Config: Copy any non-default config values here or attach the full config as a gist or file. <!-- The following sections are only required if relevant. --> Logs: Include snippet of errors in logs or stack traces here. Sometimes you can get useful information by running the program with the `RUST_BACKTRACE=full` environment variable. Finally, the IOx server has a `-vv` for verbose logging.
Project: M3 (Observability and Analysis / Observability)
File: monitoring.md

title: "Monitoring" menuTitle: "Monitoring" weight: 15 chapter: true M3DB exposes metrics via a Prometheus endpoint. If using the , you can apply a `ServiceMonitor` to have your M3DB pods automatically scraped by Prometheus: ``` kubectl apply -f https://raw.githubusercontent.com/m3db/m3db-operator/master/example/prometheus-servicemonitor.yaml ``` You can visit the "targets" page of the Prometheus UI to verify the pods are being scraped. To view these metrics using Grafana, follow the to install the M3DB Grafana dashboard.
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: real-time-flags.md

:::tip Real-time Flags are currently part of our SaaS Enterprise plans. ::: Real-time flags allow you to stream flag changes from Flagsmith downstream to connected clients. :::info You need to enable the realtime listener in the Flagsmith SDK. Please check the docs for your SDK language on how to do this. ::: Our SDK will make a long-lived request (actually a ), to our real-time infrastructure. This connection will remain open for the duration of the SDK session, listening for events from our API. When an Environment is updated in some way, either via the Flagsmith dashboard or our API, all the clients connected to that Environment stream will receive a message (actually an epoch timestamp) that alerts them to refresh their flags, which they will go ahead and do. It is then up to you, as part of the SDK integration, to reflect that new flag state within your application. Real-time flags are included within the Scale-Up and Enterprise plans. We are working to build out support for all our SDKs. We are going to prioritise client-side SDKs over server-side SDKs but are happy to take pull requests! | Language | Support | | -- | - | | Javascript | | | iOS/Swift | | | Android/Kotlin | | | Dart/Flutter | | | Language | Support | | -- | - | | Node.js | | | Java | | | .Net | | | Python | | | Ruby | | | Rust | | | Go | | | Elixir | | Per-identity overrides do not trigger an update Identity Trait updates do not trigger an update When realtime streaming is enabled within the SDK, the client will try to connect to: `eventSourceUrl + "sse/environments/" + environmentID + "/stream"`. The streaming services is built on top of , not Websockets! By default, this `eventSourceUrl` is set to `https://realtime.flagsmith.com/`. Every time flags are fetched (via identify, get flags, set traits etc) via the REST API, we update an epoch timestamp internally within the SDK, storing how fresh the flags are. Whilst connected to the streaming service, the client will receive a new epoch timestamp event if the Flagsmith Environment state has changed. If that epoch timestamp value is greater (as in more recent) than our internal timestamp we refetch the flags.
Project: Netdata (Observability and Analysis / Observability)
File: postgres_table_last_autoanalyze_time.md

This alert is triggered when the time elapsed since a PostgreSQL table was last analyzed by the AutoVacuum daemon exceeds one week. AutoVacuum is responsible for recovering storage, optimizing the database, and updating statistics used by the PostgreSQL query planner. If you receive this alert, it indicates that one or more of your PostgreSQL tables have not been analyzed recently which may impact performance. In PostgreSQL, table autoanalyze is a process carried out by the AutoVacuum daemon. This process analyzes the table contents and gathers statistics for the query planner to help it make better decisions about optimizing your queries. Regular autoanalyze is crucial for maintaining good performance in your PostgreSQL database. Check the current AutoVacuum settings: To verify if AutoVacuum is enabled and configured correctly in your PostgreSQL database, run the following SQL command: ```sql SHOW autovacuum; ``` If it returns `on`, AutoVacuum is enabled. Otherwise, enable AutoVacuum by modifying the `postgresql.conf` file, and set `autovacuum = on`. Then, restart the PostgreSQL service. Analyze the table manually: If AutoVacuum is enabled but the table has not been analyzed recently, you can manually analyze the table by running the following SQL command: ```sql ANALYZE [VERBOSE] [schemaname.]tablename; ``` Replace `[schemaname.]tablename` with the appropriate schema and table name. The optional `VERBOSE` keyword provides detailed information about the analyze process. Investigate any errors during autoanalyze: If AutoVacuum is enabled and running but you still receive this alert, check the PostgreSQL log files for any errors or issues related to the AutoVacuum process. Address any issues discovered in the logs. Monitor AutoVacuum activity: To get an overview of AutoVacuum activity, you can monitor the `pgstatprogress_vacuum` view. Run the following SQL command to inspect the view: ```sql SELECT * FROM pgstatprogress_vacuum; ``` Analyze the results to determine if there are any inefficiencies or issues with the AutoVacuum settings.
Project: Botkube (Observability and Analysis / Observability)
File: CODE_OF_CONDUCT.md

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation. Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at . All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. This Code of Conduct is adapted from the , version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html For answers to common questions about this code of conduct, see https://www.contributor-covenant.org/faq
Project: M3 (Observability and Analysis / Observability)
File: headers_optional_read_write_all.md

`M3-Metrics-Type`: If this header is set, it determines what type of metric to store this metric value as. Otherwise by default, metrics will be stored in all namespaces that are configured. You can also disable this default behavior by setting `downsample` options to `all: false` for a namespace in the coordinator config, for more see . Must be one of: `unaggregated`: Write metrics directly to configured unaggregated namespace. `aggregated`: Write metrics directly to a configured aggregated namespace (bypassing any aggregation), this requires the `M3-Storage-Policy` header to be set to resolve which namespace to write metrics to. `M3-Storage-Policy`: If this header is set, it determines which aggregated namespace to read/write metrics directly to/from (bypassing any aggregation). The value of the header must be in the format of `resolution:retention` in duration shorthand. e.g. `1m:48h` specifices 1 minute resolution and 48 hour retention. Valid time units are "ns", "us" (or "s"), "ms", "s", "m", "h". Here is of querying metrics from a specific namespace.
Project: Checkmk (Observability and Analysis / Observability)
File: 15841.md

key | value | date | 2024-03-26T10:03:03+00:00 version | 2.4.0b1 class | fix edition | cee component | core level | 2 compatible | yes This change ensures the reloading of the configuration by already running RRD processes, thereby guaranteeing that those processes are using the correct configuration. SUP-17787 CMK-16318
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-user_is_in_teams.md

category: User apiurl: '/api/v1/user/u/:uid/in_teams' title: 'Check user in teams or not' type: 'GET' sample_doc: 'user.html' layout: default Required ex. /api/v1/user/u/4/inteams?teamnames=team1,team4 Content-type: application/x-www-form-urlencoded ```team_names=team1,team2``` ```Status: 200``` ```{"message":"true"} ``` For more example, see the . For errors responses, see the .
Project: OpenCost (Observability and Analysis / Continuous Optimization)
File: CODE_OF_CONDUCT.md

As contributors and maintainers in the OpenCost community, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities. We are committed to making participation in the OpenCost community a harassment-free experience for everyone. This code of conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of behavior that contributes to a positive environment include: Demonstrating empathy and kindness toward others Being respectful of differing opinions, viewpoints, and experiences Giving and gracefully accepting constructive feedback Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience Focusing on what is best not just for us as individuals, but for the overall community Examples of unacceptable behavior include: The use of sexualized language or imagery, and sexual attention or advances of any kind Trolling, insulting or derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or email address, without their explicit permission No solicitation. This is a community to help foster innovation, education, and professional & personal networking. Other conduct which could reasonably be considered inappropriate in a professional setting Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct. By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect of managing this project. Project maintainers who do not follow or enforce the Code of Conduct may be permanently removed from the project team. Instances of abusive, harassing, or otherwise unacceptable behavior in the OpenCost community may be reported by contacting the project maintainer(s) who will try to resolve incidents without punishment, but may remove people from the project or OpenCost community at their discretion. This Code of Conduct is adapted from the Contributor Covenant (http://contributor-covenant.org), version 2.0 available at http://contributor-covenant.org/version/2/0/codeofconduct/
Project: Netdata (Observability and Analysis / Observability)
File: megacli_adapter_state.md

This alert indicates that the status of a virtual drive on your MegaRAID controller is in a degraded state. A degraded state means that the virtual drive's operating condition is not optimal, and one of the configured drives has failed or is offline. Gather more information about your virtual drives in all adapters: ``` root@netdata # megacli LDInfo -Lall -aALL ``` Check which virtual drive is in a degraded state and in which adapter. Consult the MegaRAID SAS Software User Guide [1]: Section `2.1.16` to check what is going wrong with your drives. Section `7.18` to perform any action on drives. Focus on sections `7.18.2`, `7.18.6`, `7.18.7`, `7.18.8`, `7.18.11`, and `7.18.14`. Data is priceless. Before performing any action, make sure that you have taken any necessary backup steps. Netdata is not liable for any loss or corruption of any data, database, or software.
Project: Falcon (Observability and Analysis / Observability)
File: CONTRIBUTING.md

Open-Falcon is developed in the open. Here are some of the channels we use to communicate and contribute: Mailing lists: for discussions around openfalcon usage and community support for discussions around openfalcon development Issue tracker: Use the GitHub issue tracker for the various to file bugs and features request. If you need support, please send your questions to the mailing list rather than filing a GitHub issue. Please do not ask individual project members for support. Use the channels above instead, where the whole community can help you and benefit from the solutions provided. If community support is insufficient for your situation, please refer to the Commercial Support section below. We welcome community contributions! Open-Falcon uses GitHub to manage reviews of pull requests. If you have a trivial fix or improvement, go ahead and create a pull request, addressing (with `@...`) the maintainer of this repository in the description of the pull request. If you plan to do something more involved, first discuss your ideas on our . This will avoid unnecessary work and surely give you and us a good deal of inspiration.
Project: Grafana (Observability and Analysis / Observability)
File: short_url.md

aliases: ../../httpapi/shorturl/ canonical: /docs/grafana/latest/developers/httpapi/shorturl/ description: Grafana Short URL HTTP API keywords: grafana http documentation api shortUrl labels: products: enterprise oss title: 'Short URL HTTP API ' Use this API to create shortened URLs. A short URL represents a longer URL containing complex query parameters in a smaller and simpler format. `POST /api/short-urls` Creates a short URL. Example request: ```http POST /api/short-urls HTTP/1.1 Accept: application/json Content-Type: application/json Authorization: Bearer eyJrIjoiT0tTcG1pUlY2RnVKZTFVaDFsNFZXdE9ZWmNrMkZYbk { "path": "d/TxKARsmGz/new-dashboard?orgId=1&from=1599389322894&to=1599410922894" } ``` JSON body schema: path The path to shorten, relative to the Grafana . Example response: ```http HTTP/1.1 200 Content-Type: application/json { "uid": AT76wBvGk, "url": http://localhost:3000/goto/AT76wBvGk?orgId=1 } ``` Status codes: 200 Created 400 Errors (invalid JSON, missing or invalid fields)
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_crd.md

title: "Module: lib/k8s/crd" linkTitle: "lib/k8s/crd" slug: "libk8scrd" makeCustomResourceClass(`args`, `isNamespaced`): `ReturnType`<typeof \> `deprecated` Use the version of the function that receives an object as its argument. | Name | Type | | : | : | | `args` | | | `isNamespaced` | `boolean` | `ReturnType`<typeof \> makeCustomResourceClass(`args`): `ReturnType`<typeof \> | Name | Type | | : | : | | `args` | | `ReturnType`<typeof \>
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: prometheus.md

title: Prometheus weight: 200 generated_file: true Prometheus Filter Plugin to count Incoming Records Buckets of record for instrumentation Description of metric Key name of record for instrumentation. Additional labels for this metric Metrics name Metrics type , , , {{< highlight yaml >}} apiVersion: logging.banzaicloud.io/v1beta1 kind: Flow metadata: name: demo-flow spec: filters: tag_normaliser: {} parser: removekeyname_field: true reserve_data: true parse: type: nginx prometheus: metrics: name: total_counter desc: The total number of foo in message. type: counter labels: foo: bar labels: host: ${hostname} tag: ${tag} namespace: $.kubernetes.namespace selectors: {} localOutputRefs: demo-output {{</ highlight >}} Fluentd config result: {{< highlight xml>}} <filter > @type prometheus @id logging-demo-flow2prometheus <metric> desc The total number of foo in message. name total_counter type counter <labels> foo bar </labels> </metric> <labels> host ${hostname} namespace $.kubernetes.namespace tag ${tag} </labels> </filter> {{</ highlight >}}
Project: Kuberhealthy (Observability and Analysis / Observability)
File: FLAGS.md

Available flags for use in Kuberhealthy For more configuration options, see the documentation | Flag | Description | Optional | Default | | - | - | -- | -- | | `--config` | Absolute path to a kube config file. | Yes | `$HOME/.kube/config` | | `--debug` | Bool to enable/disable debug logging. | Yes | `False` |
Project: Krkn (Observability and Analysis / Chaos Engineering)
File: application_outages.md

Scenario to block the traffic ( Ingress/Egress ) of an application matching the labels for the specified duration of time to understand the behavior of the service/other services which depend on it during downtime. This helps with planning the requirements accordingly, be it improving the timeouts or tweaking the alerts etc. ``` application_outage: # Scenario to create an outage of an application by blocking traffic duration: 600 # Duration in seconds after which the routes will be accessible namespace: <namespace-with-application> # Namespace to target - all application routes will go inaccessible if pod selector is empty pod_selector: {app: foo} # Pods to target block: [Ingress, Egress] # It can be Ingress or Egress or Ingress, Egress ``` Kraken creates a network policy blocking the ingress/egress traffic to create an outage, in case of failures before reverting back the network policy, you can delete it manually by executing the following commands to stop the outage: ``` $ oc delete networkpolicy/kraken-deny -n <targeted-namespace> ```
Project: Netdata (Observability and Analysis / Observability)
File: redis_bgsave_slow.md

This alert, `redisbgsaveslow`, indicates that the duration of the ongoing Redis RDB save operation is taking too long. This can be due to a large dataset size or a lack of CPU resources. As a result, Redis might stop serving clients for a few milliseconds, or even up to a second. Redis RDB (Redis Database) is a point-in-time snapshot of the dataset. It's a binary file that represents the dataset at the time of saving. The RDB save operation is the process of writing the dataset to disk, which occurs in the background. Check the CPU usage Use the `top` command to see if the CPU usage is unusually high. ```bash top ``` If the CPU usage is high, identify the processes that are consuming the most CPU resources and determine if they are necessary. Minimize the load by closing unnecessary processes. Analyze the dataset size Check the size of your Redis dataset using the `INFO` command: ```bash redis-cli INFO | grep "usedmemoryhuman" ``` If the dataset size is large, consider optimizing your data structure or implementing data management strategies, such as data expiration or partitioning. Monitor the Redis RDB save operation Use the following command to obtain the Redis statistics: ```bash redis-cli INFO | grep "rdblastbgsavetimesec" ``` Review the duration of the RDB save operation (rdblastbgsavetimesec). If the save operation takes an unusually long time or fails frequently, consider optimizing your Redis configuration or improving your hardware resources like CPU and disk I/O. Change the save operation frequency To limit the frequency of RDB save operations, adjust the `save` configuration directive in your Redis configuration file (redis.conf). For example, to save the dataset only after 300 seconds (5 minutes) and at least 10000 changes: ``` save 300 10000 ``` After modifying the configuration, restart the Redis service for the changes to take effect.
Project: Graylog (Observability and Analysis / Observability)
File: ColorPickerPopover.md

```js import createReactClass from 'create-react-class'; import { Button } from 'components/bootstrap'; const ColorPickerOverlayExample = createReactClass({ getInitialState() { return { color: undefined, }; }, handleColorChange(color, _, hidePopover) { hidePopover(); this.setState({ color: color }); }, render() { const { color } = this.state; return ( <div> <p>{color ? `You picked ${color}.` : 'Pick a color'}</p> <ColorPickerPopover id="example-color-picker" placement="right" color={color} triggerNode={<Button bsStyle="primary">Toggle color picker</Button>} onChange={this.handleColorChange} /> </div> ); }, }); <ColorPickerOverlayExample /> ```