v2/internal/logging/levels.go (7 lines of code) (raw):

/* * Copyright (c) Microsoft Corporation. * Licensed under the MIT license. */ package logging // These levels are defined to categorize (roughly) what a given log level means. They serve as guidelines // to help decide what level a new log should be emitted at. They are not rules that must be followed. // Keep in mind that there may be logs logged at a level higher // than Debug (the highest log level defined below). Logs between levels 4 and 10 are progressively // more verbose and are used rarely. const ( // Status logs are logs that should ALWAYS be shown. In the context of a controller, // Status logs should not be happening for every reconcile loop. Examples of good Status logs // are state changes or major problems. These probably line up very nicely with interesting // customer facing "events" as well. Status = 0 // Info logs are logs that are probably useful but may be slightly more verbose. // In the context of a controller, an Info log probably shouldn't be emitted every time through // the reconcile loop, at least in the happy path. // Examples of good Info logs include intermittent errors which we expect to be able to retry through // and object updates (think: "set ownerReference" or similar things which are not critical state changes // but are still interesting updates that aren't super verbose). Info = 1 // Verbose logs are logs that are quite verbose. In the context of a controller // they likely log on each reconcile loop. Examples of good Verbose logs include // "waiting for deployment..." or "waiting for deletion to complete..." Verbose = 2 // Debug logs are logs that are extremely verbose and log each reconcile loop (or multiple times in a single // reconcile loop). Examples include ARM request and response payloads, or request and response payloads // from APIServer. Debug = 3 )