skywalking python agent cannot report data but it has service name

[tunbb]

I am using the apache/skywalking-python:1.1.0-grpc-py3.10 base image to connect to the OAP backend address, and the address is accessible. Additionally, the SkyWalking official website states that the apache/skywalking-python:1.1.0-grpc-py3.10 agent is non-intrusive and does not require modifying the application code.

In releases before 0.7.0, you would at least need to add the following lines to your applications to get the agent attached and running, this can be tedious in many cases due to large number of services, DevOps practices and can cause problem when used with prefork servers.

So, my app code and dockerfile is as follows:

dockerfile

FROM apache/skywalking-python:1.1.0-grpc-py3.10
my app ...

EXPOSE 5000

ENV FLASK_APP=e_t.py
ENV SW_AGENT_NAME='e-t'
ENV SW_AGENT_COLLECTOR_BACKEND_SERVICES='xxx:31180'
ENV SW_AGENT_PROTOCOL='grpc'
ENV SW_AGENT_INSTANCE_NAME='e-t-instance'

ENTRYPOINT ["sw-python"]
CMD ["run", "gunicorn", "e_t:app", "--workers 2", "--bind", "0.0.0.0:5000" ]

app

if name == 'main':
app.run(debug=True, port=5000)

However, after the service makes a request to the interface, I am unable to see the request statistics in SkyWalking. Moreover, the OAP backend does not report any errors.

Then, I search for help and gpt tell me ：when using a Flask application, some basic configurations are still required to ensure that the Agent can correctly track requests. skywalking doc says

I'm not sure which situation is causing the agent to fail to report data... I have a try, using config.init in my app code like:
'''
config.init(
agent_collector_backend_services=os.getenv('SW_AGENT_COLLECTOR_BACKEND_SERVICES', 'xxx:31180'),
agent_name=os.getenv('SW_AGENT_NAME', 'e-t'),
agent_instance_name=os.getenv('SW_AGENT_INSTANCE_NAME', 'e-t-instance'),
agent_protocol=os.getenv('SW_AGENT_PROTOCOL', 'grpc'),
)
agent.start()
'''
now I get an error in my flask app as follows:

what is the problem, please help!

[wu-sheng]

From the logs, it seems to remote oap is not available. Check oap logs.

[tunbb]

no idea. oap logs seem normal. And the TTL sets 14

env |grep TTL

SW_CORE_METRICS_DATA_TTL=14

[tunbb]

some java apps are normal and can send data to oap

[tunbb]

to solve:
using -p in cmd