While Langtrace Cloud is the default destination for your traces, there are scenarios where you might need to send traces to a custom endpoint. This could be for testing, using an on-premises solution, or integrating with other systems. This guide covers two methods to achieve this: using the api_host parameter or implementing a custom exporter.

​
SDK Init options

The Langtrace.init function takes an object with the following options:
ParameterTypeDescriptionDefault Value
api_keystrYour Langtrace API key. Required for sending traces to Langtrace Cloud.-
api_host[str]The custom endpoint to send traces to.Langtrace Cloud
batch[bool]Whether to batch spans before sending.true
write_spans_to_console[bool]To allow spans to be displayed on console. Note: If you enable this, spans wont be forwarded to remote endpoint.false
custom_remote_exporter[Any]A custom exporter for remote traces. Optional.-
disable_instrumentations[dict]Instrumentations that are to be disabled or enabled. Optional.-
disable_tracing_for_functions[dict]Functions to exclude from tracing. Optional.None
service_name[str]The name of the service for which traces are generated. Optional.-
disable_logging[bool]Whether to disable logging within the SDK.false
instrumentations[dict][Typescript SDK only] This is a required option for next.js applications.-
disable_latest_version_check[bool][Typescript SDK only] Whether to disable the latest version check.false

​
api_key

The api_key option allows you to specify Langtrace project API key. The precedence order for determining the API key is as follows:
  • The x-api-key specified in environment variable OTEL_EXPORTER_OTLP_TRACES_HEADERS
  • The x-api-key specified in environment variable OTEL_EXPORTER_OTLP_HEADERS
  • The environment variable LANGTRACE_API_KEY
  • The api_key parameter in the Langtrace.init function

​
API Key as argument

from langtrace_python_sdk import langtrace
langtrace.init(
  api_key="your_api_key"
)

​
API Key as environment variable

export OTEL_EXPORTER_OTLP_TRACES_HEADERS="x-api-key=your_api_key"
# or
export OTEL_EXPORTER_OTLP_HEADERS="x-api-key=your_api_key"
# or
export LANGTRACE_API_KEY="your_api_key"

​
api_host

The api_host option allows you to specify a custom endpoint to send traces to. This is particularly useful when you want to send traces to a different endpoint than the default Langtrace Cloud. If no custom endpoint is specified, traces will be sent to Langtrace Cloud by default. The precedence order for determining the API host is as follows:
  • The environment variable LANGTRACE_API_HOST
  • The environment variable OTEL_EXPORTER_OTLP_TRACES_ENDPOINT
  • The environment variable OTEL_EXPORTER_OTLP_ENDPOINT
  • The api_host parameter in the Langtrace.init function

​
API Host as argument

from langtrace_python_sdk import langtrace
langtrace.init(
  api_host="https://example.com/"
)

​
API Host as environment variable

export LANGTRACE_API_HOST="http://localhost:3000/api/trace"
# or
export OTEL_EXPORTER_OTLP_TRACES_ENDPOINT="http://localhost:3000/api/trace"
# or
export OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:3000/api/trace"

​
batch

Allows you to specify whether to batch spans before sending. This is useful for reducing the number of requests sent to the server, which can improve performance and reduce costs.
If you are using the SDK in a script or a notebook, you might want to set this to false to see the spans as they are captured.
from langtrace_python_sdk import langtrace
langtrace.init(
  batch=False
)

​
write_spans_to_console

Allows you to specify whether to write spans to the console output. This is useful if you have a logforwarded that forwards console output or for debugging.
If this is set to true, the spans will not be sent to the remote endpoint.
from langtrace_python_sdk import langtrace
langtrace.init(
  write_spans_to_console=True
)

​
custom_remote_exporter

By defining a custom exporter, you have full control over the export process, including custom formatting or additional processing of spans before sending. If you want to send traces to a remote endpoint, instead of defining api_host, it can be done by passing a custom exporter to the custom_remote_exporter parameter in the Langtrace.init function. The custom_remote_exporter option will take precedence over the api_host option.
Using the custom_remote_exporter with a custom url will cause majority of the langtrace features (like evaluations, user feedback, etc.) to not work and should only be used if Langtrace is being used only to capture and send traces.
Here is an example of how to implement a custom exporter that demonstrates that with a custom exporter you have endless possibilities! 
import * as Langtrace from "@langtrase/typescript-sdk";
import { CustomExporter } from './custom_exporter'
Langtrace.init({
  write_spans_to_console: true,
  custom_remote_exporter: new CustomExporter("https://example.com/")
})
// Your application code here

​
disable_instrumentations

With this option, certain libraries can be either excluded or included from being traced. This enables users to have more control over what is being traced and easily filter out noisy libraries. This option can be used to exclude a library from being traced by passing the library name to the disable_instrumentations parameter in the Langtrace.init function.

​
Exclude libraries

To exclude specific vendors, you can pass the value to this parameter as follows: 
{ "all_except": ["weaviate", "gemini"] }
This way, all the instrumentations except for weaviate and gemini will be disabled.

​
Include libraries

To include specific vendors, you can pass the value to this parameter as follows: 
{ "only": ["weaviate", "gemini"] }
This way, only weaviate and gemini will be traced. For Python SDK, the vendor name can be found in the all_instrumentations variable in the repo here. For Typescript SDK, the vendor name can be found in the allInstrumentations variable in the repo here.
For more details on the implementation, refer Disable Tracing For Specific Vendors.

​
disable_tracing_for_functions

This option allows you to exclude specific functions from being traced. This can be useful if you have certain functions that you do not want to trace, such as health check functions. To exclude a function, do it the following way: 
{
	"<vendor_name_1>": ["your_function_name_1", "your_function_name_2"],
	"<vendor_name_2>": ["your_function_name_1", "your_function_name_2"]
}
For more details on the implementation, refer Disable Tracing For Functions.

​
service_name

This option allows you to specify the name of the service for which traces are generated. This is useful if you have multiple services within your application and want to trace them separately. This option overrides the attribute service.name in the trace as per the OpenTelemetry specification. The precedence order for determining the service name is as follows:
  • The environment variable OTEL_SERVICE_NAME
  • The service_name parameter in the Langtrace.init function
from langtrace_python_sdk import langtrace
langtrace.init(
  service_name="your_service_name"
)

​
disable_logging

This option allows you to disable logging within the SDK. This is useful if you have a logging system in place and do not want Langtrace to log anything. 
from langtrace_python_sdk import langtrace
langtrace.init(
  disable_logging=True
)

​
instrumentations

This argument is only applicable for Typescript SDK with Next.js. This option allows you to specify the instrumentations to be used. This is useful if you have a custom implementation of a library and want to trace it. 
import * as Langtrace from "@langtrase/typescript-sdk";
Langtrace.init({
  instrumentations: {
    openai: openai,
  },
});

​
disable_latest_version_check

This argument is only applicable for Typescript SDK. Flag to disable the latest version check. This removes any version checks that happens on every init call. 
import * as Langtrace from "@langtrase/typescript-sdk";
Langtrace.init({
  disable_latest_version_check: true,
});