feat: integrate embedded reportserver

[ansrivas]

There are three cases to consider:

if ZO_ENABLE_EMBEDDED_REPORT_SERVER=true

If running a binary, alertmanager node will spawn an embedded server running at localhost:5082.
All the requests from alert-manager will go to localhost:5082 for pdf generation related tasks.

For single node k8s deployment, as this is running in a container there is no chromium installed, so even if you set the variable to true, the report server will panic due to missing dependencies. For this situation helm chart will spawn a report-server instance which can be used.

Same for cluster deployment.

Summary by CodeRabbit

• New Features

  • Introduced a new report server for generating and sending reports.
  • Added health check and report sending endpoints.

• Improvements

  • Enhanced logging for report server operations.
  • Configurable option to skip TLS verification for report server connections.

• Bug Fixes

  • Fixed formatting issue in HTTP status request handler.

• Chores

  • Updated dependencies and configurations for the new report server module.

• Documentation

  • Added new structures and functions for email configuration, report generation, and server operations.

[hengfeiyang]

I suggest rename reportserver to report_server, also rename the directory.

[coderabbitai]

Walkthrough

The recent changes introduce a new reportserver module to the workspace, enhancing the project's reporting capabilities. This includes updates to configuration structures, logging for report server activities, and the addition of various dependencies. The reportserver module now handles report generation, email sending, and HTTP request routing. Additionally, TLS verification settings have been adjusted to support the new reporting functionalities.

Changes

File/Path	Change Summary
Cargo.toml	Added reportserver as a workspace member and updated the members list.
deny.toml	Added an exception for reportserver with the license AGPL-3.0.
src/config/src/config.rs	Introduced ReportServer struct and added new fields to existing structs for report server settings.
src/handler/http/request/status/mod.rs	Removed an extra newline before a block of code.
src/job/alert_manager.rs	Added logging for spawning an embedded report server based on configuration.
src/reportserver/Cargo.toml	Added dependencies for the reportserver project.
src/reportserver/src/lib.rs	Introduced and exported modules for models, reports, routing, and server functionality.
src/reportserver/src/models.rs	Added structs and enums for email configuration, report details, and dashboard information.
src/reportserver/src/report.rs	Added functions for generating reports, launching a headless browser, and sending emails.
src/reportserver/src/router.rs	Added HTTP request handling for generating and sending reports, along with health checks.
src/reportserver/src/server.rs	Added functionality for spawning a report server using Actix Web.
src/service/dashboards/reports.rs	Modified TLS verification behavior in the Client::builder() chain.

Sequence Diagram(s) (Beta)

sequenceDiagram
    participant User
    participant ReportServer
    participant HeadlessBrowser
    participant EmailService

    User->>ReportServer: Send report request
    ReportServer->>HeadlessBrowser: Generate report
    HeadlessBrowser->>ReportServer: Return report data
    ReportServer->>EmailService: Send report email
    EmailService->>User: Email sent confirmation

Loading

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share

• X
• Mastodon
• Reddit
• LinkedIn

Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai generate interesting stats about this repository and render them as a table.
  • @coderabbitai show all the console.log statements in this repository.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to full the review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

Actionable comments posted: 4

Outside diff range and nitpick comments (2)

src/reportserver/src/models.rs (1)

26-35: Consider adding documentation comments to ReportDashboard to explain the purpose of each field, especially variables and timerange.

src/reportserver/src/router.rs (1)

21-47: The HttpResponse structure is well-defined with appropriate use of serialization controls. Consider adding more detailed documentation for each field, especially error_detail and trace_id, to explain their usage contexts.

Review Details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between fa0233a and bbec38b.

Files ignored due to path filters (1)

• Cargo.lock is excluded by !**/*.lock

Files selected for processing (12)

• Cargo.toml (3 hunks)
• deny.toml (1 hunks)
• src/config/src/config.rs (4 hunks)
• src/handler/http/request/status/mod.rs (1 hunks)
• src/job/alert_manager.rs (1 hunks)
• src/reportserver/Cargo.toml (1 hunks)
• src/reportserver/src/lib.rs (1 hunks)
• src/reportserver/src/models.rs (1 hunks)
• src/reportserver/src/report.rs (1 hunks)
• src/reportserver/src/router.rs (1 hunks)
• src/reportserver/src/server.rs (1 hunks)
• src/service/dashboards/reports.rs (1 hunks)

Files skipped from review due to trivial changes (4)

• Cargo.toml
• deny.toml
• src/handler/http/request/status/mod.rs
• src/reportserver/Cargo.toml

Additional comments not posted (10)

src/reportserver/src/lib.rs (1)

1-6: LGTM! The module structure and public export are clearly defined.

src/reportserver/src/models.rs (2)

64-71: The default implementation for ReportTimerange is well-defined. Good use of the default trait to provide fallback values.

---

5-8: Ensure that the client field in SmtpConfig is thread-safe and properly managed since it's a static reference.

Verification successful

---

The provided context shows that AsyncSmtpTransport is initialized using Lazy from the once_cell crate, which ensures thread-safe, one-time initialization. This pattern is used in both src/reportserver/src/report.rs and src/config/src/config.rs. The SmtpConfig struct references this Lazy instance, ensuring that the client field is properly managed and thread-safe.

• src/reportserver/src/report.rs:

  pub static SMTP_CLIENT: Lazy<AsyncSmtpTransport<Tokio1Executor>> = Lazy::new(|| {
      let tls_parameters = TlsParameters::new(CONFIG.smtp.smtp_host.clone()).unwrap();
      let mut transport_builder =
          AsyncSmtpTransport::<Tokio1Executor>::builder_dangerous(&CONFIG.smtp.smtp_host)
              .port(CONFIG.smtp.smtp_port);
  
      let option = &CONFIG.smtp.smtp_encryption;
      transport_builder = if option == "starttls" {
          transport_builder.tls(Tls::Required(tls_parameters))
      } else if option == "ssltls" {
          transport_builder.tls(Tls::Wrapper(tls_parameters))
      } else {
          transport_builder
      };
      transport_builder.build()
  });

• src/config/src/config.rs:

  pub static SMTP_CLIENT: Lazy<Option<AsyncSmtpTransport<Tokio1Executor>>> = Lazy::new(|| {
      if !CONFIG.smtp.smtp_enabled {
          None
      } else {
          let tls_parameters = TlsParameters::new(CONFIG.smtp.smtp_host.clone()).unwrap();
          let mut transport_builder =
              AsyncSmtpTransport::<Tokio1Executor>::builder_dangerous(&CONFIG.smtp.smtp_host)
                  .port(CONFIG.smtp.smtp_port);
  
          let option = &CONFIG.smtp.smtp_encryption;
          transport_builder = if option == "starttls" {
              transport_builder.tls(Tls::Required(tls_parameters))
          } else if option == "ssltls" {
              transport_builder.tls(Tls::Wrapper(tls_parameters))
          } else {
              transport_builder
          };
          Some(transport_builder.build())
      }
  });

Given this context, the client field in SmtpConfig is indeed thread-safe and properly managed.

• : The client field in SmtpConfig is thread-safe and properly managed using Lazy from the once_cell crate.

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Description: Verify thread safety and lifecycle management of `AsyncSmtpTransport` instance.

# Test: Search for the initialization and usage of `AsyncSmtpTransport`.
ast-grep --lang rust --pattern $'let $_ = AsyncSmtpTransport::<Tokio1Executor>::builder_dangerous($$$)'

Length of output: 104

---

---

Script:

#!/bin/bash
# Description: Verify thread safety and lifecycle management of `AsyncSmtpTransport` instance.

# Test: Search for the initialization and usage of `AsyncSmtpTransport` with different patterns.
ast-grep --lang rust --pattern $'let $_ = AsyncSmtpTransport::<Tokio1Executor>::new($$$)'
ast-grep --lang rust --pattern $'let $_ = AsyncSmtpTransport::<Tokio1Executor>::builder($$$)'
ast-grep --lang rust --pattern $'let $_ = AsyncSmtpTransport::<Tokio1Executor>::new_with($$$)'
ast-grep --lang rust --pattern $'let $_ = AsyncSmtpTransport::<Tokio1Executor>::builder_dangerous($$$)'

# Test: Search for the usage of `SmtpConfig` to understand how `client` is managed.
ast-grep --lang rust --pattern $'SmtpConfig { $$$ }'

Length of output: 440

---

---

Script:

#!/bin/bash
# Description: Broaden the search to find any references to `AsyncSmtpTransport` and `SmtpConfig`.

# Test: Search for any references to `AsyncSmtpTransport` throughout the codebase.
rg 'AsyncSmtpTransport'

# Test: Search for any references to `SmtpConfig` throughout the codebase.
rg 'SmtpConfig'

Length of output: 1015

---

---

Script:

#!/bin/bash
# Description: Extract relevant code snippets to analyze the initialization and management of `AsyncSmtpTransport` and `SmtpConfig`.

# Extract code snippets from `src/reportserver/src/report.rs` related to `AsyncSmtpTransport`.
rg -A 10 'AsyncSmtpTransport' src/reportserver/src/report.rs

# Extract code snippets from `src/config/src/config.rs` related to `AsyncSmtpTransport`.
rg -A 10 'AsyncSmtpTransport' src/config/src/config.rs

# Extract code snippets from `src/reportserver/src/router.rs` related to `SmtpConfig`.
rg -A 10 'SmtpConfig' src/reportserver/src/router.rs

Length of output: 2505

src/reportserver/src/server.rs (1)

51-87: The graceful shutdown function handles different signals appropriately. Ensure that the signal handling is tested across different operating systems to confirm its reliability.

src/job/alert_manager.rs (1)

28-38: The logic to spawn the embedded report server based on configuration is clear and well-implemented. Ensure that the configuration flags are documented and validated during application startup.

src/reportserver/src/report.rs (1)

325-377: The send_email function is well-implemented with comprehensive error handling. Ensure that the SMTP configuration and credentials are securely managed and not logged.

Verification successful

---

The search results indicate that SMTP configuration and credentials are used in various parts of the codebase, but there is no evidence of them being logged directly. This suggests that the SMTP credentials are managed securely without being exposed in log statements.

• src/reportserver/src/router.rs
• src/reportserver/src/models.rs
• src/reportserver/src/report.rs
• src/service/dashboards/reports.rs
• src/service/alerts/destinations.rs
• src/service/alerts/mod.rs
• src/config/src/config.rs

These files contain references to SMTP configuration and credentials, but no logging statements were found that expose sensitive information.

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Description: Verify secure management of SMTP credentials.

# Test: Search for logging statements that might expose sensitive information.
rg --type rust 'log::info' | grep smtp

Length of output: 38

---

---

Script:

#!/bin/bash
# Description: Verify secure management of SMTP credentials.

# Test: Search for logging statements that might expose sensitive information at different logging levels.
rg --type rust 'log::warn' | grep smtp
rg --type rust 'log::error' | grep smtp
rg --type rust 'log::debug' | grep smtp

Length of output: 118

---

---

Script:

#!/bin/bash
# Description: Verify secure management of SMTP credentials.

# Test: Search for the usage of SMTP configuration and credentials in the codebase.
rg --type rust 'SmtpConfig'
rg --type rust 'smtp'

Length of output: 3179

src/config/src/config.rs (4)

245-245: Added ReportServer struct to the Config struct.

This addition aligns with the PR's objective to integrate an embedded report server, ensuring that the server's configuration can be managed through environment variables.

---

267-281: Introduced ReportServer struct with configuration fields.

This struct is well-defined with appropriate use of environment variables for configuration. It includes essential settings such as enabling the report server, user credentials, and network settings. This is crucial for the flexibility and security of the report server configuration.

---

299-304: Added new fields to the Chrome struct for managing Chrome browser options.

These additions provide more control over the Chrome browser's behavior when used by the report server, such as checking for default paths and managing downloads. This is important for ensuring that the embedded browser operates correctly in various deployment environments.

---

615-618: Added fields to configure the report server's URL and TLS verification behavior.

These fields are essential for defining the connection to the report server and its security settings. The ability to skip TLS verification (report_server_skip_tls_verify) can be useful in development or internal environments but should be used cautiously in production.