Skip to content
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

[Logging V2] Windows Support #28721

Closed
paynejacob opened this issue Sep 2, 2020 · 16 comments
Closed

[Logging V2] Windows Support #28721

paynejacob opened this issue Sep 2, 2020 · 16 comments
Assignees
Labels
area/logging kind/enhancement Issues that improve or augment existing functionality QA/L release-note Note this issue in the milestone's release notes
Milestone

Comments

@paynejacob
Copy link
Contributor

paynejacob commented Sep 2, 2020

Ensure we can collect logs from windows nodes.
gz#16339

@paynejacob paynejacob added this to the v2.5.x milestone Sep 2, 2020
@paynejacob paynejacob self-assigned this Sep 2, 2020
@maggieliu maggieliu added the kind/enhancement Issues that improve or augment existing functionality label Sep 21, 2020
@maggieliu maggieliu modified the milestones: v2.5.x, v2.5 - Backlog Oct 2, 2020
@dzup4uk
Copy link

dzup4uk commented Oct 13, 2020

microsoft/Windows-Containers#61
this may be helpful. As of K8s 1.19.2 (vxlan) windows pods can access kubernetes API and autodiscovery will start working.
For example filebeat can be configured as daemonset on windows nodes and will take care of windows containers logs.

@cbron cbron modified the milestones: v2.5 - Backlog, v2.5.x Nov 30, 2020
@maggieliu maggieliu modified the milestones: v2.5.x, v2.5.5 Dec 1, 2020
@nickgerace
Copy link
Contributor

nickgerace commented Dec 11, 2020

Spoke to folks on the banzaicloud Slack and filed an upstream issue from the conversation: kube-logging/logging-operator#656

@nickgerace
Copy link
Contributor

nickgerace commented Apr 10, 2021

Confirmed that logs are being shipped properly on Windows nodes from \var\log\containers.
This was validating with the following steps:

  1. Delete the opeator deployment and statefulset to render the logging system "static"
  2. Changed the fluent-bit.conf via the win-agent secret to print to stdout
  3. Delete the agent pods and tail the new pods to detect stdout
  4. Confirmed that \var\log\containers symlinks were working and that logs were being ingested properly
  5. However, discovered that \var\lib\rancher\rke\log was not being ingested, which has resulted in creation of [Logging v2] Collect RKE node logs on Windows #32021

As a result of this investigation, this issue is dependent on #32021 being solved, but the original concern that caused this to be reopened has been resolved.

Thank you for the help! @paynejacob @izaac @luthermonson

@nickgerace
Copy link
Contributor

nickgerace commented Apr 10, 2021

This issue is also dependent on #32016 's resolution.

@nickgerace
Copy link
Contributor

This can be tested for everything but airgap. The airgap backport PR is awaiting a passing build.
#32061

@izaac
Copy link
Contributor

izaac commented Apr 13, 2021

Airgap test will be done as part of #32016

@izaac
Copy link
Contributor

izaac commented Apr 13, 2021

Rancher version v2.5.8-rc2
Logging Chart version: 3.9.400-rc03
Fluentd ClusterOutput.
Windows 2019 (1809)

Logs from C:\var\log\containers are collected. I see logs in the clusteroutput also using a Windows webserver app.
RKE logs from C:\var\lib\rancher\rke\log are collected too using the additionalLoggingSources.rke.enabled=true
Ran into this issue: #32074

There is a pending Dashboard values.yaml issue that needs to be addressed: rancher/dashboard#2626

@izaac
Copy link
Contributor

izaac commented Apr 13, 2021

master-head issue: #32077

@nickgerace
Copy link
Contributor

nickgerace commented Apr 13, 2021

Opened a new issue that @izaac encountered here: rancher/dashboard#2684

Source: #28721 (comment)

The UI sets global.cattle.windows.enabled to true, but not additionalLoggingSources.rke.enabled to true because the provider is 'rke.windows' and not rke. This is a default setting that needs to be changed, and it can be fixed by setting additionalLoggingSources.rke.enabled to true manually.

To be clear: rancher/dashboard#2626 has been closed in favor of rancher/dashboard#2684

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/logging kind/enhancement Issues that improve or augment existing functionality QA/L release-note Note this issue in the milestone's release notes
Projects
None yet
Development

No branches or pull requests

8 participants