XL-LightHouse Documentation

By installing and using XL-LightHouse, you agree to the following legal terms:

• User Responsibility: Users are solely responsible for ensuring their use of the system complies with local and international laws, especially regarding cross-border data transfer and privacy.
• Indemnification: If illegal use leads to third-party claims, the user must bear all responsibility and compensate the Developer for losses.
• Developer Disclaimers:
  • The Developer is not liable for data leakage, data loss, or any direct/indirect losses caused by system issues or defects.
  • The Developer is not liable for losses resulting from the user's violation of laws.
• Data Security: While the Developer implements reasonable security measures and provides backup/recovery mechanisms, the Developer does not assume liability for data loss or damage.

In addition to the Big Data version, XL-LightHouse supports a Single-Machine Version designed for low-cost, lightweight usage.

Specifications & Use Cases:

• Minimum Requirements: A cloud server with at least 4 cores and 8GB RAM.
• Ideal For:
  • Small to medium-sized enterprises or business teams.
  • Temporary/ephemeral use cases (e.g., stress testing a new interface, troubleshooting data anomalies, or investigating sudden database pressure spikes).
  • Initial product experience or as a local environment for secondary development and debugging.

To get started with XL-LightHouse, follow these practical tutorials to set up specific business monitoring scenarios:

• Basic Setup: Create your first data metric
• UI/UX Monitoring: ICON click data statistics
• E-commerce Monitoring:
  • E-commerce order data statistics
  • Order payment status data statistics

XL-LightHouse provides several automated methods for deployment and maintenance. Detailed guides for these tasks can be found in the official documentation:

• Deployment:
  • Docker two-minute quick deployment
  • One-click deployment
• Maintenance:
  • One-click upgrade
  • Data backup
  • General daily operations

System Updates

To ensure security and stability, users should promptly install updates released by the Developer, which include bug fixes and feature enhancements.

Support Tiers

• Basic Support: Includes assistance with system deployment, configuration, and general usage questions.
• Advanced Support: Includes custom feature development and other specialized services. These require additional fees and are governed by a separate service agreement.

The Workplace component provides a context named HomePageContext that allows child components to access the current dashboard's state without prop drilling.

Context Shape

The context provides an object containing:

• homeData: An object of type HomeData representing the overview information.
• statInfo: An object of type Stat representing statistical data.

To use this in a child component, consume the context using the useContext hook.

import { useContext } from 'react';
import { HomePageContext } from '@/pages/common/context';

const MyChildComponent = () => {
  const { homeData, statInfo } = useContext(HomePageContext);
  // Use homeData and statInfo here
  return <div>...</div>;
};

The standalone version of Lighthouse uses a Log4j2 configuration that categorizes logs into several distinct files based on their severity level. This allows for easier troubleshooting by isolating specific types of events.

Logs are stored in the directory defined by the ${ldp_lighthouse_home}/logs/lighthouse-standalone/ path. Each log file uses a rolling policy where files are archived (compressed as .gz) when they reach a size of 500MB or based on a time pattern.

Key log files include:

• standalone_trace.log: Contains only TRACE level logs.
• standalone_debug.log: Contains DEBUG level logs.
• standalone_info.log: Contains INFO level logs.
• standalone_warn.log: Contains WARN level logs.
• standalone_error.log: Contains ERROR level logs.
• Console output: Displays INFO level and above.

The hadoop-env.sh file acts as the master configuration file for all Hadoop projects (YARN, HDFS, MapReduce). When configuring settings, be aware of the following precedence rules:

1. Component-specific files override master file: {yarn-env.sh|hdfs-env.sh} > hadoop-env.sh > hard-coded defaults.
2. Variable specificity overrides general variables: {YARN_xyz|HDFS_xyz} > HADOOP_xyz > hard-coded defaults.

Most defaults are configured for substitution rather than appending, allowing you to overwrite them via the command line (e.g., JAVA_HOME=/usr/java/testing hdfs dfs -ls).

The application uses a GlobalContext to manage user preferences for language and visual themes. This context is accessible to all components within the BrowserRouter.

Context Values:

• lang: The current language string (e.g., 'zh-CN', 'en-US').
• setLang: Function to update the language.
• theme: The current theme string (e.g., 'light').
• setTheme: Function to update the theme.

These values are persisted using the useStorage hook with keys arco-lang and arco-theme.