Error monitoring and logging in No-Code - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to start logging errors to a file named 'app.log'.

No-Code

logging.basicConfig(filename=[1], level=logging.ERROR)

Drag options to blanks, or click blank then click option'

A'debug.log'

B'error.log'

C'logfile.txt'

D'app.log'

Attempts:

3 left

💡 Hint

Common Mistakes

Using the wrong filename string.

Forgetting to put quotes around the filename.

The filename parameter should be set to 'app.log' to log errors to that file.

2fill in blank

medium

Complete the code to log an error message 'File not found'.

No-Code

logging.[1]('File not found')

Drag options to blanks, or click blank then click option'

Ainfo

Berror

Cwarning

Ddebug

Attempts:

3 left

💡 Hint

Common Mistakes

Using logging.info() instead of logging.error().

Using logging.debug() which is for debugging, not errors.

Use logging.error() to log error messages.

3fill in blank

hard

Fix the error in the code to catch exceptions and log them.

No-Code

try:
    open('data.txt')
except Exception as [1]:
    logging.error('Failed to open file')

Drag options to blanks, or click blank then click option'

Ae

Bexception

Cex

Derror

Attempts:

3 left

💡 Hint

Common Mistakes

Using reserved words like 'exception' as variable names.

Using names that are not valid identifiers.

The variable name after 'as' is commonly 'e' to represent the exception.

4fill in blank

hard

Fill both blanks to log the exception message with traceback.

No-Code

except Exception as [1]:
    logging.error('Error occurred: %s', [2], exc_info=True)

Drag options to blanks, or click blank then click option'

Ae

Cerror

Dex

Attempts:

3 left

💡 Hint

Common Mistakes

Using different variable names in the two blanks.

Not passing the exception variable to the logging call.

The exception variable 'e' is used to log the error message and traceback.

5fill in blank

hard

Fill both blanks to create a dictionary comprehension that logs only errors with code greater than 400.

No-Code

error_logs = [1]: [2] for } in logs.items() if {{BLANK_2} > 400

Drag options to blanks, or click blank then click option'

A{k

Bcode

C(k, code)

D}

Attempts:

3 left

💡 Hint

Common Mistakes

Not using curly braces to start the dictionary comprehension.

Using wrong variable names for keys or values.

The dictionary comprehension starts with '{k:', uses 'code' as value, and 'k' as key variable.

Practice

1. What is the main purpose of error monitoring in DevOps?

easy

A. To design user interfaces

B. To write code faster

C. To watch logs and alert when problems happen

D. To create backups of data

Solution

1. Step 1: Understand error monitoring

   Error monitoring means watching logs and system behavior to catch problems quickly.

2. Step 2: Identify the main goal

   The main goal is to alert teams when issues occur so they can fix them fast.

3. Final Answer:

   To watch logs and alert when problems happen -> Option C

4. Quick Check:

   Error monitoring = alert on problems [OK]

Hint: Error monitoring alerts you about problems fast [OK]

Common Mistakes:

• Confusing monitoring with coding tasks
• Thinking monitoring creates backups
• Mixing monitoring with UI design

2. Which of the following is the correct way to log an error message in a typical logging system?

easy

A. log.error('File not found')

B. log.write('File not found')

C. log.print('File not found')

D. log.send('File not found')

Solution

1. Step 1: Identify standard logging methods

   Common logging libraries use methods like error(), info(), debug() to log messages by severity.

2. Step 2: Match the correct method for error logging

   The method error() is used to log error messages specifically.

3. Final Answer:

   log.error('File not found') -> Option A

4. Quick Check:

   Use error() to log errors [OK]

Hint: Use log.error() to record error messages [OK]

Common Mistakes:

• Using print or write instead of error method
• Confusing logging with sending messages
• Using undefined methods like send()

3. Given this log snippet:

2024-06-01 10:00:00 ERROR Database connection failed
2024-06-01 10:01:00 INFO Retry attempt 1
2024-06-01 10:02:00 ERROR Database connection failed

What will an error monitoring tool most likely do?

medium

A. Alert the team twice for the two errors

B. Ignore the errors because they are repeated

C. Only alert once for the first error

D. Convert errors to info messages

Solution

1. Step 1: Analyze the log entries

   There are two ERROR entries about database connection failure at different times.

2. Step 2: Understand typical monitoring alert behavior

   Monitoring tools alert for each error event unless configured to group them.

3. Final Answer:

   Alert the team twice for the two errors -> Option A

4. Quick Check:

   Each error triggers an alert [OK]

Hint: Each error log usually triggers an alert [OK]

Common Mistakes:

• Assuming repeated errors are ignored
• Thinking alerts merge automatically
• Confusing error and info log levels

4. You see this error in your monitoring dashboard:
Failed to parse log file: Unexpected token at line 10
What is the most likely cause?

medium

A. User permissions are missing

B. Monitoring tool is offline

C. Network connection is slow

D. Log file has a syntax error or corrupted entry

Solution

1. Step 1: Interpret the error message

   The message says 'Unexpected token at line 10' which means the log file content is malformed or corrupted.

2. Step 2: Identify the cause of parsing failure

   Parsing fails when the log format is broken or has invalid characters.

3. Final Answer:

   Log file has a syntax error or corrupted entry -> Option D

4. Quick Check:

   Parsing error = bad log format [OK]

Hint: Parsing errors mean log file format is broken [OK]

Common Mistakes:

• Blaming network or permissions without checking logs
• Assuming monitoring tool is offline
• Ignoring the line number in error

5. You want to reduce noise from repeated error alerts in your monitoring system. Which approach is best?

hard

A. Increase log verbosity to debug level

B. Configure alert grouping to combine similar errors within a time window

C. Disable error logging completely

D. Restart the monitoring server daily

Solution

1. Step 1: Understand alert noise problem

   Repeated error alerts can overwhelm teams and hide real issues.

2. Step 2: Choose a solution to reduce noise

   Grouping alerts for similar errors within a time frame reduces alert volume without losing info.

3. Step 3: Evaluate other options

   Disabling logging loses data, increasing verbosity adds noise, restarting server doesn't reduce alerts.

4. Final Answer:

   Configure alert grouping to combine similar errors within a time window -> Option B

5. Quick Check:

   Alert grouping reduces noise [OK]

Hint: Group alerts to reduce repeated error noise [OK]

Common Mistakes:

• Turning off logging loses important info
• Increasing verbosity adds more noise
• Restarting server doesn't fix alert noise