Move node type from network address to service level[Need storage module update]

[wu-sheng]

Update in this pull request

1. Rename src_layer to node_type for NetworkAddressInventory. Break change, need discussion. Is this acceptable? @peng-yongsheng It will benefit for long term.
2. Add node_type for ServiceInventory.
3. Add NodeType for backend code use. spanLayer would not be used in backend codes, except the trace analysis. We need to do more refactor to avoid using enum value of protocol level in our storage.

[wu-sheng]

This is my proposal mail thread. Consider this PR is step 1, Inventory changes (PROPOSAL ONLY).

---

I am thinking about SQL and Database analysis solution for a whole. Here are some my thoughts and proposal. Feedback are welcome.
Also, because I am not working on implementing this feature, all these are suggestions.

Inventory changes

All metadata need register in SkyWalking. So Database instances do the same. Right now, we provide a virtual service metadata for each database instance.
So we need following adjustments.

1. network_address_inventory src_layer should be renamed as type. I know we want to keep upgrade compatible, this is just a suggestion. Because SrcLayer is hard to understand for people.
2. service_instance_inventory and service_inventory add field type to bring network_address_inventory's type to higher level.

SQL Register

SQL statements are tons in real cluster, we can't and needn't to register and do for all of them.
First of all, we just register slow SQL statement, such as slower than 10ms? (Could provide settings for this).
Also, keep register number has a limit, such as, for each collector instance, would do slow SQL statement register over 10K times in 30mins.
Then, because register is async way, we could have two solution

1. Use file buffer, waiting for register finished. Like mesh and trace data register. Advantage, one time slow SQL could be catch. Disadvantage, not quickly, especially the application codes are bad, don't use prepare statement.
2. Just send the register, and don't wait. Ignore this time access. Disadvantage, clearly, some first times slow SQL access missed. Delay the opportunities to address slow SQL.
   We could discuss about these two.

Source

DBAccess source should be easy, include, db service id, latency, timestamp, status.
SQLStatement sources could be in two

1. ServiceSQLStatement, use service id + sql id as entity id, and include latency, timestamp, status.
2. EndpointSQLStatement, use endpoint id + sql id as entity id, and include latency, timestamp, status.

Query and UI

1. Show Database service list
2. Show metric for database cpm, SLA, avg response time, even P99/95...
3. Show topN slow SQL from ServiceSQLStatement by aggregation query in database query page.
4. Show topN slow SQL from EndpointSQLStatement with Endpoint related info attached in database query page.

Here are all in my mind.

[coveralls]

Coverage decreased (-0.01%) to 14.306% when pulling 978b4d8 on nodetype into 2840f8e on master.

[wu-sheng]

@liuhaoyang Please consider the proposal in ml and here(same) is just suggestion. I am doing this pull request just to try to make service and address inventory fixed. That is all.

All things about SQL register, analysis, and visualization are still depending on your leadership.

[wu-sheng]

I am moving to adjust Zipkin, Jaeger and OC format analysis :)

[peng-yongsheng]

Maybe we should better discuss the SQL and database analysis in a specific issue or pull request.

The source of layer is agent. Where is it from? Is there a specification that defined? Opentracing? TracingContext?

[wu-sheng]

Which name? Layer? That is from tracing field. Adrian gave that name. But only make sense in trace, not inventory. Right?

[peng-yongsheng]

All right. I'm not good at the name definition. This break change is not difficult for users to upgrade backend to the new edition. A database script could fixed it.

[wu-sheng]

@peng-yongsheng @liuhaoyang Tests are done. Look like working now.