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

Is it worth mentioning how to enable logs? #60

Open
xynova opened this issue Apr 2, 2020 · 12 comments
Open

Is it worth mentioning how to enable logs? #60

xynova opened this issue Apr 2, 2020 · 12 comments
Labels
enhancement New feature or request P4 low priority issues triaged Scoped and ready for work

Comments

@xynova
Copy link

xynova commented Apr 2, 2020

Should the examples show how to turn logs on?

  metadata = {
    gce-container-declaration = module.container_metadata_spec.metadata_value
    google-logging-enabled = "true"
  }

@morgante
Copy link
Contributor

morgante commented Apr 2, 2020

Sure, feel free to add this to an example.

@morgante morgante added enhancement New feature or request P4 low priority issues triaged Scoped and ready for work labels Apr 2, 2020
@dts
Copy link
Contributor

dts commented Apr 29, 2020

This would be great - I am happy to push up a PR if that's helpful, but I don't want to step on anyones toes.

@xynova
Copy link
Author

xynova commented Apr 29, 2020

no worries, I forked the project in order to do it and never did, sorry about that

@morgante
Copy link
Contributor

A PR would definitely be appreciated.

@dts
Copy link
Contributor

dts commented Apr 30, 2020

@morgante - let me know if you had something else in mind r.e. PR #62

morgante added a commit that referenced this issue Apr 30, 2020
Add logging and monitoring to simple example (r.e. #60)
@0xjjpa
Copy link

0xjjpa commented Jun 1, 2020

Sorry to comment on a closed thread, but albeit the logging seems to be enabled, it seems that unless we enable gcplogs this would effectively only log the machine vitals and not the logs of the actual container.

It seems that there's already some train of thought for enabling this, but I've yet to find an example on how to enable this for a COS image. From my understanding, we need to add something like the following in the COS image under /etc/docker/daemon.json:

{
  "log-driver": "gcplogs",
  "log-opts": {
    "gcp-project": "removed",
    "env": "host"
  }
}

Right now I'm using cos-dev-84-13078-0-0 and I get the following information:

$ cat /etc/docker/daemon.json
{
        "live-restore": true,
        "storage-driver": "overlay2",
        "mtu": 1460
}

In short, even if we add this line (i.e. google-logging-enabled = "true") in our VM metadata definition, the agent has yet to know how to send the container information to GCP. Would that be a correct statement?

@morgante
Copy link
Contributor

morgante commented Jun 1, 2020

Interesting, I haven't dug into this but can reopen the issue if someone wants to investigate further.

@0xjjpa
Copy link

0xjjpa commented Jun 2, 2020

Probably relevant to link GoogleCloudPlatform/konlet#56, as it seems that there's an ongoing conversation there about the limitation of enabling gcplogs on Konlet as of right now.

@DeanBrunt
Copy link

For anyone who stumbles upon this. I had this issue and it was remedied by adding the google-logging-enabled metadata key.

I got caught out as I was using a non-default service account which didn't have permissions to write logs, so the agent came up and then was unable to write to Stackdriver.

Once I sorted the permissions out all was fine.

@meldron
Copy link

meldron commented Mar 9, 2021

Edit: so in the end google-logging-enabled = "true" was enough.

I guess I also had some problems with the service key or something like that.

It took me awhile to get logging working:

locals {
  additional_metadata = {
    google-logging-enabled    = "true"
    google-monitoring-enabled = "true"
    user-data                 = file("./etc/gcp_logging_driver.yml")
  }
}

module "gce-container" {
  source  = "terraform-google-modules/container-vm/google"
  version = "~> 2.0"

  container = {
    image = local.image
    env   = local.env_vars
  }

  restart_policy = "Always"
}

module "mig_template" {
  source               = "terraform-google-modules/vm/google//modules/instance_template"
  version              = "6.1.0"
  network              = google_compute_network.default.self_link
  subnetwork           = google_compute_subnetwork.default.self_link
  machine_type         = var.machine_type
  service_account      = var.service_account
  name_prefix          = var.mig_name
  source_image_family  = "cos-stable"
  source_image_project = "cos-cloud"
  source_image         = reverse(split("/", module.gce-container.source_image))[0]
  metadata             = merge(local.additional_metadata, map("gce-container-declaration", module.gce-container.metadata_value))
  tags                 = local.target_tags
  labels = {
    "container-vm" = module.gce-container.vm_container_label
  }
}

Content of ./etc/gcp_logging_driver.yml

#cloud-config

write_files:
    - path: /etc/docker/daemon.json
      content: '{"log-driver":"gcplogs"}'

runcmd:
    - systemctl restart docker

This user-data scripts overwrites /etc/docker/daemon.json with

{"log-driver":"gcplogs"}

@fdcds
Copy link

fdcds commented Jan 13, 2022

FYI: There is a new Google Ops Agent that is supposed to replace the legacy logging and monitoring agents, but it does not appear to support Google Container-Optimized OS: GoogleCloudPlatform/ops-agent#325

@hakuno
Copy link

hakuno commented Dec 13, 2022

For anyone who stumbles upon this. I had this issue and it was remedied by adding the google-logging-enabled metadata key.

I got caught out as I was using a non-default service account which didn't have permissions to write logs, so the agent came up and then was unable to write to Stackdriver.

Once I sorted the permissions out all was fine.

It solves the problem. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request P4 low priority issues triaged Scoped and ready for work
Projects
None yet
Development

No branches or pull requests

8 participants