Not a customer? Click the 'Start a free trial' link to begin a 30-day SaaS trial of our product and to join our community.
Existing Cisco AppDynamics customers should click the 'Sign In' button to authenticate to access the community
on 06-15-2018 09:20 AM - edited on 02-04-2019 02:37 PM by Nina.Wolinsky
This article is intended for anyone currently using the 4.3.7 (or earlier) or 4.4.0 version of the AppDynamics C++/C SDK, which uses a separate Proxy (JVM) task, and who wishes to upgrade to the 4.4.1 libagent-based (proxy-less) version of the SDK.
There are numerous reasons to do so, the most important is that this newer version represents the current and future SDK architecture. The next reason is resource consumption. The older proxy-based version uses a stand-alone JVM, which has a minimum 300M footprint, all of the additional CPU consumption that a JVM requires, the use of socket files (which consume up to 8K worth of open file descriptors), not to mention the necessary coordination of user IDs and file permissions between the Agent and Proxy tasks, and any additional SELinux policy concerns that that introduces.
These reasons all justify moving to the newer SDK architecture, and we strongly encourage you to do so.
The differences between the old and new formats, although not 100% ABI compatible, will be quite easy to navigate. The major differences in porting to the new version is that the configuration-structure initialization. In the previous version, you needed to allocate the structure, then initialize each field. In the newer version, the structure is already allocated, you simply call setter functions to fill in the fields you wish to set.
Presuming you were declaring the fields as const chars (in both versions).
For example:
const char APP_NAME[] = "SampleC"; const char TIER_NAME[] = "SampleCTier1"; const char NODE_NAME[] = "SampleCNode1"; const char CONTROLLER_HOST[] = "osxlttyu"; const int CONTROLLER_PORT = 8080; const char CONTROLLER_ACCOUNT[] = "customer1"; const char CONTROLLER_ACCESS_KEY[] = "SJ5b2m7d1$354"; const int CONTROLLER_USE_SSL = 0;
In the older versions (4.2 through 4.3.7 and 4.4.0) within your own code you would declare and allocate an appd_config struct
and assign the settings to it.
For example:
appd_config cfg; appd_config_init(&cfg); cfg.app_name = (char*)APP_NAME; cfg.tier_name = (char*)TIER_NAME; cfg.node_name = (char*)NODE_NAME; cfg.controller.host = (char*)CONTROLLER_HOST; cfg.controller.port = CONTROLLER_PORT; cfg.controller.account = (char*)CONTROLLER_ACCOUNT; cfg.controller.access_key = (char*)CONTROLLER_ACCESS_KEY; cfg.controller.use_ssl = CONTROLLER_USE_SSL; #ifdef _WIN32 cfg.appd_proxy_config.tcp_control_port = PROXY_CTRL_PORT; cfg.appd_proxy_config.tcp_request_port = PROXY_REQ_PORT; cfg.appd_proxy_config.tcp_reporting_port = PROXY_REP_PORT; #endif cfg.init_timeout_ms = 0;
In the newer SDK (4.3.8 & 4.4.1 and later versions) you would call an initialization routine (which zeros the internally stored structure and returns its address) then call setter methods for each field in that structure.
For example:
appd_config* cfg = appd_config_init(); // appd_config_init() resets the configuration object and pass back an handle/pointer appd_config_set_app_name(cfg, APP_NAME); appd_config_set_tier_name(cfg, TIER_NAME); appd_config_set_node_name(cfg, NODE_NAME); appd_config_set_controller_host(cfg, CONTROLLER_HOST); appd_config_set_controller_port(cfg, CONTROLLER_PORT); appd_config_set_controller_account(cfg, CONTROLLER_ACCOUNT); appd_config_set_controller_access_key(cfg, CONTROLLER_ACCESS_KEY); appd_config_set_controller_use_ssl(cfg, CONTROLLER_USE_SSL);
appd_sdk_init()
, which will spawn a limited number of tasks to handle collating BTs, Metrics, Snapshots, etc., and communicate them to the Controller (all within the same user ID as the calling method). Documentation: Using the C/C++ Agent SDK
Documentation: C/C++ Agent SDK Reference
Thank you! Your submission has been received!
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form