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

title: "Roadmap" linkTitle: "Roadmap" weight: 10 slug: roadmap This document highlights some ideas for major features we'd like to implement in the near future. To get a more complete overview of planned features and current work, see the . Note that these are not ordered by priority. We have a but it needs work before it can be effectively utilised by different backends. We also don't provide an official set of dashboards and alerts to our users yet. This is one of the most requested features and something we will tackle in the immediate future. We also plan on publishing debs, rpms along with guides on how to run Cortex on bare-metal. Cortex server has a simple authentication mechanism (X-Scope-OrgId) but users can't use the multitenancy features out of the box without complicated proxy configuration. It's hard to support all the different authentication mechanisms used by different companies but plan to have a simple but opinionated auth-gateway that provides value out of the box. The configuration could be as simple as: ``` tenants: name: infra-team password: basic-auth-password name: api-team password: basic-auth-password2 ``` We have all the metrics to track how many series, samples and queries each tenant is sending but don't have dashboards that help with this. We plan to have dashboards and UIs that will help operators monitor and control each tenants usage out of the box. Downsampling means storing fewer samples, e.g. one per minute instead of one every 15 seconds. This makes queries over long periods more efficient. It can reduce storage space slightly if the full-detail data is discarded. Cortex blocks storage supports deleting all data for a tenant after a time period (e.g. 3 months, 1 year), but we would also like to have custom retention for subsets of metrics (e.g. delete server metrics but retain business metrics). let you link metric samples to other data, such as distributed tracing. As of early 2021 Prometheus will collect exemplars and send them via remote write, but Cortex needs to be extended to handle them. Scalability has always been a focus for the project, but there is a lot more work to be done. We can now scale to 100s of Millions of active series but 1 Billion active series is still an unknown.
Project: Kepler (Observability and Analysis / Observability)
File: Release_workflow.md

title: Kepler dev and release schedule authors: Sam Yuan reviewers: n/A, though github approvers: n/A, though github creation-date: 2023-07 last-updated: 2023-07 tracking-links: # link to related GitHub issues https://github.com/sustainable-computing-io/kepler/pull/759 https://github.com/sustainable-computing-io/kepler-action/issues/50 https://github.com/sustainable-computing-io/local-dev-cluster/issues/22 https://github.com/sustainable-computing-io/kepler/pull/760 At Jul 2023, during development of we found we'd better have a release schedule as guidance to handle breaking changes between repos. Major for our (customer github action)[https://github.com/sustainable-computing-io/kepler-action], but also for breaking changes in kepler which may influence kepler-operator, model server and other repos. This document is created for our next steps integration works, as in we discussed about flexible pipelines with paramterable to reduce the influence of version bump up. In this rfc, we are going to discuss how to make CI, dashboard, bi-weekly meeting together. Create a pre release page as enhancement of this . To further considering reducing CVE by automatic build, enhance CI to support build latest code on default branch and latest release branch bi weekly? Hence provide something as security patch bi weekly. To avoid breaking changes in customer CI breaks other Repos. Make a schedule for customer CI and other repos release. Self host github action integration. Considering with privilege issue on self hosted BM... mark out of scope. Test scope as metric of OS, CPU arch, k8s platform is collecting in our google doc as meeting minutes, and some OS/CPU arch may need to test manually or by other CI tooling support, hence mark it out of scope today. As we have kepler release in each 3 months. | Timeline | Action | || | | 1~2 month | kepler-action development, maybe just bump version in regular | | 2 month | kepler-action release | | 2~3 month | kepler, kepler-helm-chat, kepler-operator... default branch switch to kepler action | | 3 month | kepler release | | 3~3+1 month | kepler-helm-chat, kepler-operator... default branch switch to latest kepler release | and we also provide pre release for kepler, kepler operator etc... to make a regular build as security patch for CVE fixing. n/A I suppose this rfc itself is a proposal as workflow. n/A n/A n/A We can use https://docs.github.com/en/actions/managing-issues-and-pull-requests/scheduling-issue-creation to schedule those works. n/A, leave to PR to discussion. n/A n/A n/A n/A
Project: Netdata (Observability and Analysis / Observability)
File: redis_master_link_down.md

The `redismasterlink_down` alert is triggered when there is a disconnection between a Redis master and its slave for more than 10 seconds. This alert indicates a potential problem with the replication process and can impact the data consistency across multiple instances. Check the Redis logs Examine the Redis logs for any errors or issues regarding the disconnection between the master and slave instances. By default, Redis log files are located at `/var/log/redis/redis.log`. Look for messages related to replication, network errors or timeouts. ``` grep -i "replication" /var/log/redis/redis.log grep -i "timeout" /var/log/redis/redis.log ``` Check the Redis replication status Connect to the Redis master using the `redis-cli` tool, and execute the `INFO` command to get the detailed information about the master instance: ``` redis-cli INFO REPLICATION ``` Also, check the replication status on the slave instance. If you have access to the IP address and port of the slave, connect to it and run the same `INFO` command. Verify the network connection between the master and slave instances Test the network connectivity using `ping` and `telnet` or `nc` commands, ensuring that the connection between the master and slave instances is stable and there are no issues with firewalls or network policies. ``` ping <slaveipaddress> telnet <slaveipaddress> <redis_port> ``` Restart the Redis instances (if needed) If Redis instances are experiencing issues or are unable to reconnect, consider restarting them. Be cautious as restarting instances might result in data loss or consistency issues. ``` sudo systemctl restart redis ``` Monitor the situation After addressing the potential issues, keep an eye on the Redis instances to ensure that the problem doesn't reoccur.
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-9-0-0-beta1.md

hide_menu: true labels: products: cloud enterprise oss title: Release notes for Grafana 9.0.0-beta1 <!-- Auto generated by update changelog github action --> AccessControl: Add setting for permission cache. (Enterprise) AccessControl: Check dashboard permissions for reports. (Enterprise) Auth: Remove grafana ui dependency to the aws sdk. , BasicRoles: Add API endpoint to reset basic roles permissions to factory. (Enterprise) LDAP Mapping: Allow Grafana Admin mapping without org role. , Licensing: Only enforce total number of users. (Enterprise) Loki: do not convert NaN to null. , Report: API support for multiple dashboards. (Enterprise) Report: Support sending embedded image in the report email. (Enterprise) Report: UI for multiple dashboards. (Enterprise) Reporting: Remove redundant empty attachment when export to CSV is enabled. (Enterprise) SAML: Implement Name Templates for assertionattributename option. (Enterprise) SSE/Alerting: Support prom instant vector responses. , Tracing: Add trace to metrics config behind feature toggle. , Fix: Prevent automatic parsing of string data types to numbers. , Prometheus: Fix inconsistent labels in exemplars resulting in marshal json error. , In the Loki data source, for consistency and performance reasons, we changed how we represent `NaN` (not a number) values received from Loki. In the past versions, we converted these to `null` in the frontend (for dashboard and explore), and kept as `NaN` in the alerting path. Starting with this version, we will always keep it as `NaN`. This change should be mostly invisible for the users. Issue The dependency to is moved from to the plugin. This means that any plugin that use SIGV4 auth need to pass a SIGV4 editor component as a prop to the `DataSourceHttpSettings` component. Issue
Project: Graylog (Observability and Analysis / Observability)
File: ThemeProvider.md

is created in `src/theme/GraylogThemeProvider.jsx` and is used in `src/index.jsx` to wrap the entire application. This will allow developers to access all `theme` props in each component. In most cases, on a new component, you can access the `theme` prop via Styled-Components like the following: ```jsx static const StyledElement = styled.div(({ theme }) => css` background-color: ${theme.colors.global.contentBackground}; `); ``` If you need to base some styles off of props, you can access them as well. ```jsx static const StyledElement = styled.div<{ wide: boolean }>(({ wide, theme }) => css` background-color: ${theme.colors.global.contentBackground}; width: ${wide ? '100%' : '50%'}; `); // usage <StyledElement wide> ``` If you do not need the theme colors in your component ```jsx static const StyledElement = styled.div` opacity: 0.5; `; ```
Project: Grafana Pyroscope (Observability and Analysis / Observability)
File: LICENSING.md

License names used in this document are as per . The default license for this project is . The following directories and their subdirectories are licensed under Apache-2.0: ``` pkg/agent/profiler pkg/agent/ebpfspy packages/pyroscope-flamegraph packages/pyroscope-models ``` The following directories and their subdirectories are under the original upstream licenses, all of them ship the entire license text they are under. ``` vendor/ ```
Project: Ddosify (Observability and Analysis / Observability)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: '' labels: bug assignees: '' Describe the bug A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior: Go to '...' Click on '....' Scroll down to '....' See error Expected behavior A clear and concise description of what you expected to happen. Screenshots If applicable, add screenshots to help explain your problem. System (please complete the following information): OS: [e.g. MacOS] Ddosify Version [e.g. v0.15.1] Additional context Add any other context about the problem here.
Project: Grafana (Observability and Analysis / Observability)
File: view-state-health.md

aliases: ../../alerting/alerting-rules/view-state-health/ # /docs/grafana/<GRAFANA_VERSION>/alerting/alerting-rules/view-state-health canonical: https://grafana.com/docs/grafana/latest/alerting/manage-notifications/view-state-health/ description: View the state and health of alert rules keywords: grafana alert rules keep last state guide state health labels: products: cloud enterprise oss title: View alert state and history weight: 420 An alert rule and its corresponding alert instances can transition through distinct states during their . There are three key components that helps us understand the behavior of our alerts: : Refers to the state of the individual alert instances. : Determined by the "worst state" among its alert instances. : Indicates the status in cases of `Error` or `NoData` events. To view the state and health of your alert rules: In the left-side menu, click Alerts & IRM and then Alerting. Click Alert rules to view the list of existing alerts. Click an alert rule to view its state, health, and state history. Use the State history view to get insight into how your alert instances behave over time. View information on when a state change occurred, what the previous state was, the current state, any other alert instances that changed their state at the same time as well as what the query value was that triggered the change. {{% admonition type="note" %}} Open source users must in order to be able to access the view. {{% /admonition %}} To access the State history view, complete the following steps. Navigate to Alerts & IRM -> Alerting -> Alert rules. Click an alert rule. Select Show state history. The State history view opens. The timeline view at the top displays a timeline of changes for the past hour, so you can track how your alert instances are behaving over time. The bottom part shows the alert instances, their previous and current state, the value of each part of the expression and a unique set of labels. Common labels are displayed at the top to make it easier to identify different alert instances. From the timeline view, hover over a time to get an automatic display of all the changes that happened at that particular moment. These changes are displayed in real time in the timestamp view at the bottom of the page. The timestamp view is a list of all the alert instances that changed state at that point in time. The visualization only displays 12 instances by default. The value shown for each instance is for each part of the expression that was evaluated. Click the labels to filter and narrow down the results. {{< figure src="/media/docs/alerting/state-history.png" max-width="750px" >}} {{% docs/reference %}} {{% /docs/reference %}}
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: orange.md

is a leading network operator for mobile, broadband internet, and fixed line telecommunications. It has its own new Infrastructure as a Service solution designed to host different types of Workloads. We wanted a tool that we could leverage to test the containerized control plane of our private cloud, so we came across Litmus, it has the following benefits. It is designed for Kubernetes workload It has wide variety of generic test cases for Kubernetes workload and Infrastructure It can be used to trigger customized validations It is easy to Integrate with our existing automation framework We explored Litmus to validate the resiliency of our private telco cloud by covering the following areas. Testing resiliency of Control plane Kubernetes Infrastructure Validating the HA of different control plane services Testing inter dependency among different open source applications Litmus has has a wide variety of generic test cases for Kubernetes workload and Infrastructure and provides a very easy way for end-to-end automation of resiliency test cases.
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: jira.md

title: Jira description: View your Flagsmith flags inside Jira sidebar_position: 10 View your Flagsmith flags inside Jira. :::tip The Jira integration is currently only supported with our hosted Flagsmith SaaS service. We are working on making it possible for those self hosting Flagsmith to use their own Jira app. Stay tuned! ::: You need to provide your Flagsmith API key to Jira. You can get your API key by going to `Account > Keys` in Flagsmith. In Jira, add the app from the . When prompted, add the Flagsmith API key. If you are a member of more than one Organisation, select the Organisation you want to associate with the Integration. Otherwise you can skip this step. Go back to the Jira project, click `Project Settings > Connect Flagsmith project` and select the Flagsmith Project you want to associate. Click Save. Open a ticket and click the Flagsmith button: Select the Flag you want to associate with the Jira ticket: Flag states now show inside Jira: You can associate multiple flags to a single Jira ticket.
Project: Grafana Mimir (Observability and Analysis / Observability)
File: overrides-exporter.md

aliases: ../../../operators-guide/architecture/components/overrides-exporter/ description: The overrides-exporter exports Prometheus metrics containing the configured per-tenant limits. menuTitle: (Optional) Overrides-exporter title: (Optional) Grafana Mimir overrides-exporter weight: 110 Grafana Mimir supports applying overrides on a per-tenant basis. A number of overrides configure limits that prevent a single tenant from using too many resources. The overrides-exporter component exposes limits as Prometheus metrics so that operators can understand how close tenants are to their limits. For more information about configuring overrides, refer to . The overrides-exporter must be explicitly enabled. {{< admonition type="warning" >}} The metrics emitted by the overrides-exporter have high cardinality. It's recommended to run only a single replica of the overrides-exporter to limit that cardinality. {{< /admonition >}} With a `runtime.yaml` file as follows: <!-- prettier-ignore-start --> ```yaml overrides: "user1": ingestionburstsize: 350000 ingestion_rate: 350000 maxglobalseriespermetric: 300000 maxglobalseriesperuser: 300000 ``` <!-- prettier-ignore-end --> Run the overrides-exporter by providing the `-target`, and `-runtime-config.file` flags: ``` mimir -target=overrides-exporter -runtime-config.file=runtime.yaml ``` After the overrides-exporter starts, you can to use `curl` to inspect the tenant overrides: ```bash curl -s http://localhost:8080/metrics | grep cortexlimitsoverrides ``` The output metrics look similar to the following: ```console cortexlimitsoverrides{limitname="ingestionburst_size",user="user1"} 350000 cortexlimitsoverrides{limitname="ingestionrate",user="user1"} 350000 cortexlimitsoverrides{limitname="maxglobalseriesper_metric",user="user1"} 300000 cortexlimitsoverrides{limitname="maxglobalseriesper_user",user="user1"} 300000 ``` With these metrics, you can set up alerts to know when tenants are close to hitting their limits before they exceed them.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_deployment.Deployment.md

title: "Class: Deployment" linkTitle: "Deployment" slug: "libk8sdeployment.Deployment" .Deployment `any` `Deployment` new Deployment(`json`) | Name | Type | | : | : | | `json` | | makeKubeObject<KubeDeployment\>('Deployment').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<KubeDeployment\>('Deployment').className `get` spec(): `any` `any` _ `get` status(): `any` `any` getContainers(): [] [] _ getMatchLabelsList(): `string`[] `string`[] _ `Static` apiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeDeployment\>('Deployment').apiList _ `Static` `Optional` getAuthorization(`arg`, `resourceAttrs?`): `any` | Name | Type | | : | : | | `arg` | `string` | | `resourceAttrs?` | | `any` makeKubeObject<KubeDeployment\>('Deployment').getAuthorization _ `Static` getErrorMessage(`err?`): ``null`` \| `string` | Name | Type | | : | : | | `err?` | ``null`` \| | ``null`` \| `string` makeKubeObject<KubeDeployment\>('Deployment').getErrorMessage _ `Static` useApiGet(`onGet`, `name`, `namespace?`, `onError?`): `void` | Name | Type | | : | : | | `onGet` | (...`args`: `any`) => `void` | | `name` | `string` | | `namespace?` | `string` | | `onError?` | (`err`: ) => `void` | `void` makeKubeObject<KubeDeployment\>('Deployment').useApiGet _ `Static` useApiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeDeployment\>('Deployment').useApiList _ `Static` useGet(`name`, `namespace?`): , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] | Name | Type | | : | : | | `name` | `string` | | `namespace?` | `string` | , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] makeKubeObject<KubeDeployment\>('Deployment').useGet _ `Static` useList(`opts?`): , (`items`: `any`) => `void`] | Name | Type | | : | : | | `opts?` | | , (`items`: `any`) => `void`] makeKubeObject<KubeDeployment\>('Deployment').useList
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-user_logout.md

category: User apiurl: '/api/v1/user/logout' title: 'Logout' type: 'GET' sample_doc: 'user.html' layout: default Required Sends back a collection of things. ```Status: 200``` ```{"message":"logout successful"}``` For more example, see the . For errors responses, see the .
Project: Checkmk (Observability and Analysis / Observability)
File: 16478.md

key | value | date | 2024-03-18T13:20:24+00:00 version | 2.4.0b1 class | feature edition | cee component | rest-api level | 1 compatible | yes This werk adds endpoints to the REST-API for managing SAML connections. This includes listing, creating and deleting of connections.
Project: M3 (Observability and Analysis / Observability)
File: headers_optional_read_limits.md

`M3-Limit-Max-Series`: If this header is set it will override any configured per query time series limit. If the limit is hit, it will either return a partial result or an error based on the require exhaustive configuration set.<br /> `M3-Limit-Max-Docs`: If this header is set it will override any configured per query time series * blocks limit (docs limit). If the limit is hit, it will either return a partial result or an error based on the require exhaustive configuration set.<br /> `M3-Limit-Require-Exhaustive`: If this header is set it will override any configured require exhaustive setting. If "true" it will return an error if query hits a configured limit (such as series or docs limit) instead of a partial result. Otherwise if "false" it will return a partial result of the time series already matched with the response header `M3-Results-Limited` detailing the limit that was hit and a warning included in the response body.
Project: Elastic (Observability and Analysis / Observability)
File: to_geopoint.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Converts an input value to a `geo_point` value. A string will only be successfully converted if it respects WKT Point format. ``` ROW wkt = "POINT(42.97109630194 14.7552534413725)" | EVAL pt = TO_GEOPOINT(wkt) ```
Project: Beats (Observability and Analysis / Observability)
File: module-checklist.md

name: New Module / Dataset about: "Meta issue to track the creation, updating of a new module or dataset." This checklist is intended for Devs which create or update a module to make sure modules are consistent. For a metricset to go GA, the following criterias should be met: [ ] Supported versions are documented [ ] Supported operating systems are documented (if applicable) [ ] Integration tests exist [ ] System tests exist [ ] Automated checks that all fields are documented [ ] Documentation and [ ] Dashboards exists (if applicable) [ ] Kibana Home Tutorial (if applicable) Open PR against Kibana repo with tutorial. Examples can be found . [ ] Test log files exist for the grok patterns [ ] Generated output for at least 1 log file exists [ ] Example `data.json` exists and an automated way to generate it exists (`go test -data`) [ ] Test environment in Docker exist for integration tests